4:03 a.m.
Hello,
We were having a discussion about unit testing keycloak-js in this PR:
https://github.com/keycloak/keycloak/pull/5946 (closed).
An easy way would be to extract it into a separate repository and write
unit tests there.This would bring further benefits:
- keycloak.js can be refactored to Typescript
- file can be split in multiple modules
- independent versioning from keycloak/keycloak would enable deprecating
legacy Promises by enabling developers to use the keycloak-js version that
works for them
- keycloak-js-bower could also be deprecated.
Guillaume Vincent previously proposed rewriting the Javascript Adapter (
https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html).
Extracting it, writing tests for it and rewriting it afterwords is an
option less prone to breaking changes.
I have some free time and could start work on this.
What do you think? Should I set up a repo so we can talk over code?
Cheers,
Armin
6:31 a.m.
On 11/26/2019 5:03 AM, Armin Roșu wrote:
Hello,
We were having a discussion about unit testing keycloak-js in this PR:
https://github.com/keycloak/keycloak/pull/5946 (closed).
An easy way would be to extract it into a separate repository and write
unit tests there.This would bring further benefits:
There are advantages and
disadvantages to putting keycloak-js in a
separate repo.
The main advantage I see for having it in the same repo with Keycloak
server is that keycloak.js version is always synced with the Keycloak
server version. For any client/server system there are always nasty
issues that crop up when client and server versions diverge.
- keycloak.js can be refactored to Typescript
There are definite advantages in code
quality when you use TypeScript.
This is both in the maintainability of the source code and the quality
of the generated keycloak.js file. If we know there are dedicated
resources to develop the Typescript version and the associated test
suite then I'm all for it. But that might be a big "if".
- file can be split in multiple modules
- independent versioning from keycloak/keycloak would enable deprecating
legacy Promises by enabling developers to use the keycloak-js version that
works for them
- keycloak-js-bower could also be deprecated.
Guillaume Vincent previously proposed rewriting the Javascript Adapter (
https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html).
Extracting it, writing tests for it and rewriting it afterwords is an
option less prone to breaking changes.
I have some free time and could start work on this.
What do you think? Should I set up a repo so we can talk over code?
Cheers,
Armin
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:09 a.m.
keycloak.js doesn't have to be in the same repository to make sure it is
compatible or release at the same time. Just look at the Node.js adapter
for example.
If we want to rewrite keycloak.js using modern approaches and clean it up.
I would introduce a new repository with a new version of keycloak.js that
doesn't have to worry about backwards compatibility. That can also be
tested using modern JS test tools.
That way we can maintain/deprecate the old keycloak.js and eventually
replace it with the new modern version.
In the future we should also not have a dependency on keycloak.js in our
admin console and new account console. Basically best practices state that
if you have both SPA and REST APIs on the same domain use cookies and
confidential clients, not tokens in the browser and public clients.
On Tue, 26 Nov 2019 at 13:34, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 11/26/2019 5:03 AM, Armin Roșu wrote:
> Hello,
>
> We were having a discussion about unit testing keycloak-js in this PR:
> https://github.com/keycloak/keycloak/pull/5946 (closed).
>
> An easy way would be to extract it into a separate repository and write
> unit tests there.This would bring further benefits:
There are advantages and disadvantages to putting keycloak-js in a
separate repo.
The main advantage I see for having it in the same repo with Keycloak
server is that keycloak.js version is always synced with the Keycloak
server version. For any client/server system there are always nasty
issues that crop up when client and server versions diverge.
>
> - keycloak.js can be refactored to Typescript
There are definite advantages in code quality when you use TypeScript.
This is both in the maintainability of the source code and the quality
of the generated keycloak.js file. If we know there are dedicated
resources to develop the Typescript version and the associated test
suite then I'm all for it. But that might be a big "if".
> - file can be split in multiple modules
> - independent versioning from keycloak/keycloak would enable deprecating
> legacy Promises by enabling developers to use the keycloak-js version
that
> works for them
> - keycloak-js-bower could also be deprecated.
>
> Guillaume Vincent previously proposed rewriting the Javascript Adapter (
>
https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
).
> Extracting it, writing tests for it and rewriting it afterwords is an
> option less prone to breaking changes.
>
>
> I have some free time and could start work on this.
>
> What do you think? Should I set up a repo so we can talk over code?
>
> Cheers,
> Armin
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:10 a.m.
With regards to a new version of keycloak.js the question comes up if
AppAuth-JS [1] can be used instead.
[1] https://github.com/openid/AppAuth-JS
On Tue, 26 Nov 2019 at 16:09, Stian Thorgersen <sthorger(a)redhat.com> wrote:
keycloak.js doesn't have to be in the same repository to make
sure it is
compatible or release at the same time. Just look at the Node.js adapter
for example.
If we want to rewrite keycloak.js using modern approaches and clean it up.
I would introduce a new repository with a new version of keycloak.js that
doesn't have to worry about backwards compatibility. That can also be
tested using modern JS test tools.
That way we can maintain/deprecate the old keycloak.js and eventually
replace it with the new modern version.
In the future we should also not have a dependency on keycloak.js in our
admin console and new account console. Basically best practices state that
if you have both SPA and REST APIs on the same domain use cookies and
confidential clients, not tokens in the browser and public clients.
On Tue, 26 Nov 2019 at 13:34, Stan Silvert <ssilvert(a)redhat.com> wrote:
> On 11/26/2019 5:03 AM, Armin Roșu wrote:
> > Hello,
> >
> > We were having a discussion about unit testing keycloak-js in this PR:
> > https://github.com/keycloak/keycloak/pull/5946 (closed).
> >
> > An easy way would be to extract it into a separate repository and write
> > unit tests there.This would bring further benefits:
> There are advantages and disadvantages to putting keycloak-js in a
> separate repo.
>
> The main advantage I see for having it in the same repo with Keycloak
> server is that keycloak.js version is always synced with the Keycloak
> server version. For any client/server system there are always nasty
> issues that crop up when client and server versions diverge.
> >
> > - keycloak.js can be refactored to Typescript
> There are definite advantages in code quality when you use TypeScript.
> This is both in the maintainability of the source code and the quality
> of the generated keycloak.js file. If we know there are dedicated
> resources to develop the Typescript version and the associated test
> suite then I'm all for it. But that might be a big "if".
> > - file can be split in multiple modules
> > - independent versioning from keycloak/keycloak would enable deprecating
> > legacy Promises by enabling developers to use the keycloak-js version
> that
> > works for them
> > - keycloak-js-bower could also be deprecated.
> >
> > Guillaume Vincent previously proposed rewriting the Javascript Adapter (
> >
> https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
> ).
> > Extracting it, writing tests for it and rewriting it afterwords is an
> > option less prone to breaking changes.
> >
> >
> > I have some free time and could start work on this.
> >
> > What do you think? Should I set up a repo so we can talk over code?
> >
> > Cheers,
> > Armin
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:49 a.m.
This is a great idea, splitting this client out into a separate repository
will allow us to be more flexible and efficient in developing out the
JavaScript adapter. Also being able to use tooling that is common in the
community such as using a proper bundler for dependencies, writing modern
ES2015 code, shipping compatible ES5 code to those who need it and writing
type safe code using TypeScript could be a huge boon to the project and
development speed. Moving everything to NPM should also give us proper
control over deprecations, where now we cannot easily deprecate and remove
functionality since there is no version control when loading the static
assets. It also allows us to improve the testing situation by moving away
from the current and outdated testing methods.
I would be very interested in helping out with the development of this
library so let me know if I can be of any help. If we're going with a new
library I would also propose that we rename the library to
'keycloak-client' on NPM since the fact that it is hosted there should
already indicate that we're talking about JavaScript and perhaps publish it
to `@keycloak` organisation on NPM. I'd also like to propose to move issue
management of this project to Github, as it decreases the effort to
contribute to the project.
On Tue, Nov 26, 2019 at 4:15 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
With regards to a new version of keycloak.js the question comes up
if
AppAuth-JS [1] can be used instead.
[1] https://github.com/openid/AppAuth-JS
On Tue, 26 Nov 2019 at 16:09, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> keycloak.js doesn't have to be in the same repository to make sure it is
> compatible or release at the same time. Just look at the Node.js adapter
> for example.
>
> If we want to rewrite keycloak.js using modern approaches and clean it
up.
> I would introduce a new repository with a new version of keycloak.js that
> doesn't have to worry about backwards compatibility. That can also be
> tested using modern JS test tools.
>
> That way we can maintain/deprecate the old keycloak.js and eventually
> replace it with the new modern version.
>
> In the future we should also not have a dependency on keycloak.js in our
> admin console and new account console. Basically best practices state
that
> if you have both SPA and REST APIs on the same domain use cookies and
> confidential clients, not tokens in the browser and public clients.
>
> On Tue, 26 Nov 2019 at 13:34, Stan Silvert <ssilvert(a)redhat.com> wrote:
>
>> On 11/26/2019 5:03 AM, Armin Roșu wrote:
>> > Hello,
>> >
>> > We were having a discussion about unit testing keycloak-js in this PR:
>> > https://github.com/keycloak/keycloak/pull/5946 (closed).
>> >
>> > An easy way would be to extract it into a separate repository and
write
>> > unit tests there.This would bring further benefits:
>> There are advantages and disadvantages to putting keycloak-js in a
>> separate repo.
>>
>> The main advantage I see for having it in the same repo with Keycloak
>> server is that keycloak.js version is always synced with the Keycloak
>> server version. For any client/server system there are always nasty
>> issues that crop up when client and server versions diverge.
>> >
>> > - keycloak.js can be refactored to Typescript
>> There are definite advantages in code quality when you use TypeScript.
>> This is both in the maintainability of the source code and the quality
>> of the generated keycloak.js file. If we know there are dedicated
>> resources to develop the Typescript version and the associated test
>> suite then I'm all for it. But that might be a big "if".
>> > - file can be split in multiple modules
>> > - independent versioning from keycloak/keycloak would enable
deprecating
>> > legacy Promises by enabling developers to use the keycloak-js version
>> that
>> > works for them
>> > - keycloak-js-bower could also be deprecated.
>> >
>> > Guillaume Vincent previously proposed rewriting the Javascript
Adapter (
>> >
>>
https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
>> ).
>> > Extracting it, writing tests for it and rewriting it afterwords is an
>> > option less prone to breaking changes.
>> >
>> >
>> > I have some free time and could start work on this.
>> >
>> > What do you think? Should I set up a repo so we can talk over code?
>> >
>> > Cheers,
>> > Armin
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:46 a.m.
You could also start with something simple, just move the package.json,
tooling (bundling, unit testing) in the same folder with an index.js.
I am working on my side to create a version in Typescript for modern
browsers without cookie or iframe.
It would be more interesting to converge efforts in the same direction.
But it's up to the Keycloak team to initiate the movement.
I have also some time for this effort.
On Tue, Nov 26, 2019 at 4:53 PM Jon Koops <jonkoops(a)gmail.com> wrote:
This is a great idea, splitting this client out into a separate
repository
will allow us to be more flexible and efficient in developing out the
JavaScript adapter. Also being able to use tooling that is common in the
community such as using a proper bundler for dependencies, writing modern
ES2015 code, shipping compatible ES5 code to those who need it and writing
type safe code using TypeScript could be a huge boon to the project and
development speed. Moving everything to NPM should also give us proper
control over deprecations, where now we cannot easily deprecate and remove
functionality since there is no version control when loading the static
assets. It also allows us to improve the testing situation by moving away
from the current and outdated testing methods.
I would be very interested in helping out with the development of this
library so let me know if I can be of any help. If we're going with a new
library I would also propose that we rename the library to
'keycloak-client' on NPM since the fact that it is hosted there should
already indicate that we're talking about JavaScript and perhaps publish it
to `@keycloak` organisation on NPM. I'd also like to propose to move issue
management of this project to Github, as it decreases the effort to
contribute to the project.
On Tue, Nov 26, 2019 at 4:15 PM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> With regards to a new version of keycloak.js the question comes up if
> AppAuth-JS [1] can be used instead.
>
> [1] https://github.com/openid/AppAuth-JS
>
> On Tue, 26 Nov 2019 at 16:09, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
> > keycloak.js doesn't have to be in the same repository to make sure it
is
> > compatible or release at the same time. Just look at the Node.js
adapter
> > for example.
> >
> > If we want to rewrite keycloak.js using modern approaches and clean it
> up.
> > I would introduce a new repository with a new version of keycloak.js
that
> > doesn't have to worry about backwards compatibility. That can also be
> > tested using modern JS test tools.
> >
> > That way we can maintain/deprecate the old keycloak.js and eventually
> > replace it with the new modern version.
> >
> > In the future we should also not have a dependency on keycloak.js in
our
> > admin console and new account console. Basically best practices state
> that
> > if you have both SPA and REST APIs on the same domain use cookies and
> > confidential clients, not tokens in the browser and public clients.
> >
> > On Tue, 26 Nov 2019 at 13:34, Stan Silvert <ssilvert(a)redhat.com>
wrote:
> >
> >> On 11/26/2019 5:03 AM, Armin Roșu wrote:
> >> > Hello,
> >> >
> >> > We were having a discussion about unit testing keycloak-js in this
PR:
> >> > https://github.com/keycloak/keycloak/pull/5946 (closed).
> >> >
> >> > An easy way would be to extract it into a separate repository and
> write
> >> > unit tests there.This would bring further benefits:
> >> There are advantages and disadvantages to putting keycloak-js in a
> >> separate repo.
> >>
> >> The main advantage I see for having it in the same repo with Keycloak
> >> server is that keycloak.js version is always synced with the Keycloak
> >> server version. For any client/server system there are always nasty
> >> issues that crop up when client and server versions diverge.
> >> >
> >> > - keycloak.js can be refactored to Typescript
> >> There are definite advantages in code quality when you use TypeScript.
> >> This is both in the maintainability of the source code and the quality
> >> of the generated keycloak.js file. If we know there are dedicated
> >> resources to develop the Typescript version and the associated test
> >> suite then I'm all for it. But that might be a big "if".
> >> > - file can be split in multiple modules
> >> > - independent versioning from keycloak/keycloak would enable
> deprecating
> >> > legacy Promises by enabling developers to use the keycloak-js
version
> >> that
> >> > works for them
> >> > - keycloak-js-bower could also be deprecated.
> >> >
> >> > Guillaume Vincent previously proposed rewriting the Javascript
> Adapter (
> >> >
> >>
>
https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
> >> ).
> >> > Extracting it, writing tests for it and rewriting it afterwords is
an
> >> > option less prone to breaking changes.
> >> >
> >> >
> >> > I have some free time and could start work on this.
> >> >
> >> > What do you think? Should I set up a repo so we can talk over code?
> >> >
> >> > Cheers,
> >> > Armin
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Guillaume Vincent
Senior Software Engineer
Red Hat <https://www.redhat.com>
<https://www.redhat.com>
3:19 a.m.
I like this idea, at the moment it is very hard for JS developers to add
some new features into our js adapter, especially when it comes to writing
tests as it is in Java. However, we should first discuss what benefits it
will have to write/rewrite something new, which will require a lot of work,
when we can use something that is already here, as Stian pointed out, for
example: [1]. Is there anybody who already tried some third party library
who could share her/his experiences?
[1] https://github.com/openid/AppAuth-JS
On Wed, Nov 27, 2019 at 7:48 AM Guillaume Vincent <gvincent(a)redhat.com>
wrote:
You could also start with something simple, just move the
package.json,
tooling (bundling, unit testing) in the same folder with an index.js.
I am working on my side to create a version in Typescript for modern
browsers without cookie or iframe.
It would be more interesting to converge efforts in the same direction.
But it's up to the Keycloak team to initiate the movement.
I have also some time for this effort.
On Tue, Nov 26, 2019 at 4:53 PM Jon Koops <jonkoops(a)gmail.com> wrote:
> This is a great idea, splitting this client out into a separate
repository
> will allow us to be more flexible and efficient in developing out the
> JavaScript adapter. Also being able to use tooling that is common in the
> community such as using a proper bundler for dependencies, writing modern
> ES2015 code, shipping compatible ES5 code to those who need it and
writing
> type safe code using TypeScript could be a huge boon to the project and
> development speed. Moving everything to NPM should also give us proper
> control over deprecations, where now we cannot easily deprecate and
remove
> functionality since there is no version control when loading the static
> assets. It also allows us to improve the testing situation by moving away
> from the current and outdated testing methods.
>
> I would be very interested in helping out with the development of this
> library so let me know if I can be of any help. If we're going with a new
> library I would also propose that we rename the library to
> 'keycloak-client' on NPM since the fact that it is hosted there should
> already indicate that we're talking about JavaScript and perhaps publish
it
> to `@keycloak` organisation on NPM. I'd also like to propose to move
issue
> management of this project to Github, as it decreases the effort to
> contribute to the project.
>
>
>
> On Tue, Nov 26, 2019 at 4:15 PM Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
> > With regards to a new version of keycloak.js the question comes up if
> > AppAuth-JS [1] can be used instead.
> >
> > [1] https://github.com/openid/AppAuth-JS
> >
> > On Tue, 26 Nov 2019 at 16:09, Stian Thorgersen <sthorger(a)redhat.com>
> > wrote:
> >
> > > keycloak.js doesn't have to be in the same repository to make sure it
> is
> > > compatible or release at the same time. Just look at the Node.js
> adapter
> > > for example.
> > >
> > > If we want to rewrite keycloak.js using modern approaches and clean
it
> > up.
> > > I would introduce a new repository with a new version of keycloak.js
> that
> > > doesn't have to worry about backwards compatibility. That can also be
> > > tested using modern JS test tools.
> > >
> > > That way we can maintain/deprecate the old keycloak.js and eventually
> > > replace it with the new modern version.
> > >
> > > In the future we should also not have a dependency on keycloak.js in
> our
> > > admin console and new account console. Basically best practices state
> > that
> > > if you have both SPA and REST APIs on the same domain use cookies and
> > > confidential clients, not tokens in the browser and public clients.
> > >
> > > On Tue, 26 Nov 2019 at 13:34, Stan Silvert <ssilvert(a)redhat.com>
> wrote:
> > >
> > >> On 11/26/2019 5:03 AM, Armin Roșu wrote:
> > >> > Hello,
> > >> >
> > >> > We were having a discussion about unit testing keycloak-js in
this
> PR:
> > >> > https://github.com/keycloak/keycloak/pull/5946 (closed).
> > >> >
> > >> > An easy way would be to extract it into a separate repository
and
> > write
> > >> > unit tests there.This would bring further benefits:
> > >> There are advantages and disadvantages to putting keycloak-js in a
> > >> separate repo.
> > >>
> > >> The main advantage I see for having it in the same repo with
Keycloak
> > >> server is that keycloak.js version is always synced with the
Keycloak
> > >> server version. For any client/server system there are always nasty
> > >> issues that crop up when client and server versions diverge.
> > >> >
> > >> > - keycloak.js can be refactored to Typescript
> > >> There are definite advantages in code quality when you use
TypeScript.
> > >> This is both in the maintainability of the source code and the
quality
> > >> of the generated keycloak.js file. If we know there are dedicated
> > >> resources to develop the Typescript version and the associated test
> > >> suite then I'm all for it. But that might be a big
"if".
> > >> > - file can be split in multiple modules
> > >> > - independent versioning from keycloak/keycloak would enable
> > deprecating
> > >> > legacy Promises by enabling developers to use the keycloak-js
> version
> > >> that
> > >> > works for them
> > >> > - keycloak-js-bower could also be deprecated.
> > >> >
> > >> > Guillaume Vincent previously proposed rewriting the Javascript
> > Adapter (
> > >> >
> > >>
> >
>
https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
> > >> ).
> > >> > Extracting it, writing tests for it and rewriting it afterwords
is
> an
> > >> > option less prone to breaking changes.
> > >> >
> > >> >
> > >> > I have some free time and could start work on this.
> > >> >
> > >> > What do you think? Should I set up a repo so we can talk over
code?
> > >> >
> > >> > Cheers,
> > >> > Armin
> > >> > _______________________________________________
> > >> > keycloak-dev mailing list
> > >> > keycloak-dev(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > >>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Guillaume Vincent
Senior Software Engineer
Red Hat <https://www.redhat.com>
<https://www.redhat.com>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:24 a.m.
I don't have any specific experience using another OpenID library. I think
the question here should be to ask what functionality does the Keycloak
library provide that a 'normal' OpenID client does not? Or what Keycloak
specific functionality do we want to provide to our users?
On Wed, Nov 27, 2019 at 10:19 AM Michal Hajas <mhajas(a)redhat.com> wrote:
I like this idea, at the moment it is very hard for JS developers to
add
some new features into our js adapter, especially when it comes to writing
tests as it is in Java. However, we should first discuss what benefits it
will have to write/rewrite something new, which will require a lot of work,
when we can use something that is already here, as Stian pointed out, for
example: [1]. Is there anybody who already tried some third party library
who could share her/his experiences?
[1] https://github.com/openid/AppAuth-JS
On Wed, Nov 27, 2019 at 7:48 AM Guillaume Vincent <gvincent(a)redhat.com>
wrote:
> You could also start with something simple, just move the package.json,
> tooling (bundling, unit testing) in the same folder with an index.js.
>
> I am working on my side to create a version in Typescript for modern
> browsers without cookie or iframe.
> It would be more interesting to converge efforts in the same direction.
> But it's up to the Keycloak team to initiate the movement.
>
> I have also some time for this effort.
>
>
> On Tue, Nov 26, 2019 at 4:53 PM Jon Koops <jonkoops(a)gmail.com> wrote:
>
> > This is a great idea, splitting this client out into a separate
> repository
> > will allow us to be more flexible and efficient in developing out the
> > JavaScript adapter. Also being able to use tooling that is common in the
> > community such as using a proper bundler for dependencies, writing
> modern
> > ES2015 code, shipping compatible ES5 code to those who need it and
> writing
> > type safe code using TypeScript could be a huge boon to the project and
> > development speed. Moving everything to NPM should also give us proper
> > control over deprecations, where now we cannot easily deprecate and
> remove
> > functionality since there is no version control when loading the static
> > assets. It also allows us to improve the testing situation by moving
> away
> > from the current and outdated testing methods.
> >
> > I would be very interested in helping out with the development of this
> > library so let me know if I can be of any help. If we're going with a
> new
> > library I would also propose that we rename the library to
> > 'keycloak-client' on NPM since the fact that it is hosted there should
> > already indicate that we're talking about JavaScript and perhaps
> publish it
> > to `@keycloak` organisation on NPM. I'd also like to propose to move
> issue
> > management of this project to Github, as it decreases the effort to
> > contribute to the project.
> >
> >
> >
> > On Tue, Nov 26, 2019 at 4:15 PM Stian Thorgersen <sthorger(a)redhat.com>
> > wrote:
> >
> > > With regards to a new version of keycloak.js the question comes up if
> > > AppAuth-JS [1] can be used instead.
> > >
> > > [1] https://github.com/openid/AppAuth-JS
> > >
> > > On Tue, 26 Nov 2019 at 16:09, Stian Thorgersen <sthorger(a)redhat.com>
> > > wrote:
> > >
> > > > keycloak.js doesn't have to be in the same repository to make
sure
> it
> > is
> > > > compatible or release at the same time. Just look at the Node.js
> > adapter
> > > > for example.
> > > >
> > > > If we want to rewrite keycloak.js using modern approaches and clean
> it
> > > up.
> > > > I would introduce a new repository with a new version of keycloak.js
> > that
> > > > doesn't have to worry about backwards compatibility. That can
also
> be
> > > > tested using modern JS test tools.
> > > >
> > > > That way we can maintain/deprecate the old keycloak.js and
> eventually
> > > > replace it with the new modern version.
> > > >
> > > > In the future we should also not have a dependency on keycloak.js in
> > our
> > > > admin console and new account console. Basically best practices
> state
> > > that
> > > > if you have both SPA and REST APIs on the same domain use cookies
> and
> > > > confidential clients, not tokens in the browser and public clients.
> > > >
> > > > On Tue, 26 Nov 2019 at 13:34, Stan Silvert
<ssilvert(a)redhat.com>
> > wrote:
> > > >
> > > >> On 11/26/2019 5:03 AM, Armin Roșu wrote:
> > > >> > Hello,
> > > >> >
> > > >> > We were having a discussion about unit testing keycloak-js
in
> this
> > PR:
> > > >> > https://github.com/keycloak/keycloak/pull/5946 (closed).
> > > >> >
> > > >> > An easy way would be to extract it into a separate repository
and
> > > write
> > > >> > unit tests there.This would bring further benefits:
> > > >> There are advantages and disadvantages to putting keycloak-js in
a
> > > >> separate repo.
> > > >>
> > > >> The main advantage I see for having it in the same repo with
> Keycloak
> > > >> server is that keycloak.js version is always synced with the
> Keycloak
> > > >> server version. For any client/server system there are always
> nasty
> > > >> issues that crop up when client and server versions diverge.
> > > >> >
> > > >> > - keycloak.js can be refactored to Typescript
> > > >> There are definite advantages in code quality when you use
> TypeScript.
> > > >> This is both in the maintainability of the source code and the
> quality
> > > >> of the generated keycloak.js file. If we know there are
dedicated
> > > >> resources to develop the Typescript version and the associated
test
> > > >> suite then I'm all for it. But that might be a big
"if".
> > > >> > - file can be split in multiple modules
> > > >> > - independent versioning from keycloak/keycloak would enable
> > > deprecating
> > > >> > legacy Promises by enabling developers to use the
keycloak-js
> > version
> > > >> that
> > > >> > works for them
> > > >> > - keycloak-js-bower could also be deprecated.
> > > >> >
> > > >> > Guillaume Vincent previously proposed rewriting the
Javascript
> > > Adapter (
> > > >> >
> > > >>
> > >
> >
> https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
> > > >> ).
> > > >> > Extracting it, writing tests for it and rewriting it
afterwords
> is
> > an
> > > >> > option less prone to breaking changes.
> > > >> >
> > > >> >
> > > >> > I have some free time and could start work on this.
> > > >> >
> > > >> > What do you think? Should I set up a repo so we can talk
over
> code?
> > > >> >
> > > >> > Cheers,
> > > >> > Armin
> > > >> > _______________________________________________
> > > >> > keycloak-dev mailing list
> > > >> > keycloak-dev(a)lists.jboss.org
> > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> keycloak-dev mailing list
> > > >> keycloak-dev(a)lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
>
> Guillaume Vincent
>
> Senior Software Engineer
>
> Red Hat <https://www.redhat.com>
> <https://www.redhat.com>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:36 a.m.
I think it would be worth to evaluate AppAuth at least. Not sure about
others. I certainly wouldn't consider libraries that are only maintained by
other IdPs.
keycloak-js-next should be generic OIDC library that supports other IdPs if
we end up creating one.
Perhaps AppAuth does what we want, or perhaps it can be a dependency that
does the OAuth flows, or perhaps we just do our own from scratch.
On Wed, 27 Nov 2019 at 12:25, Jon Koops <jonkoops(a)gmail.com> wrote:
I don't have any specific experience using another OpenID
library. I think
the question here should be to ask what functionality does the Keycloak
library provide that a 'normal' OpenID client does not? Or what Keycloak
specific functionality do we want to provide to our users?
On Wed, Nov 27, 2019 at 10:19 AM Michal Hajas <mhajas(a)redhat.com> wrote:
> I like this idea, at the moment it is very hard for JS developers to add
> some new features into our js adapter, especially when it comes to writing
> tests as it is in Java. However, we should first discuss what benefits it
> will have to write/rewrite something new, which will require a lot of work,
> when we can use something that is already here, as Stian pointed out, for
> example: [1]. Is there anybody who already tried some third party library
> who could share her/his experiences?
>
> [1] https://github.com/openid/AppAuth-JS
>
> On Wed, Nov 27, 2019 at 7:48 AM Guillaume Vincent <gvincent(a)redhat.com>
> wrote:
>
>> You could also start with something simple, just move the package.json,
>> tooling (bundling, unit testing) in the same folder with an index.js.
>>
>> I am working on my side to create a version in Typescript for modern
>> browsers without cookie or iframe.
>> It would be more interesting to converge efforts in the same direction.
>> But it's up to the Keycloak team to initiate the movement.
>>
>> I have also some time for this effort.
>>
>>
>> On Tue, Nov 26, 2019 at 4:53 PM Jon Koops <jonkoops(a)gmail.com> wrote:
>>
>> > This is a great idea, splitting this client out into a separate
>> repository
>> > will allow us to be more flexible and efficient in developing out the
>> > JavaScript adapter. Also being able to use tooling that is common in
>> the
>> > community such as using a proper bundler for dependencies, writing
>> modern
>> > ES2015 code, shipping compatible ES5 code to those who need it and
>> writing
>> > type safe code using TypeScript could be a huge boon to the project and
>> > development speed. Moving everything to NPM should also give us proper
>> > control over deprecations, where now we cannot easily deprecate and
>> remove
>> > functionality since there is no version control when loading the static
>> > assets. It also allows us to improve the testing situation by moving
>> away
>> > from the current and outdated testing methods.
>> >
>> > I would be very interested in helping out with the development of this
>> > library so let me know if I can be of any help. If we're going with a
>> new
>> > library I would also propose that we rename the library to
>> > 'keycloak-client' on NPM since the fact that it is hosted there
should
>> > already indicate that we're talking about JavaScript and perhaps
>> publish it
>> > to `@keycloak` organisation on NPM. I'd also like to propose to move
>> issue
>> > management of this project to Github, as it decreases the effort to
>> > contribute to the project.
>> >
>> >
>> >
>> > On Tue, Nov 26, 2019 at 4:15 PM Stian Thorgersen
<sthorger(a)redhat.com>
>> > wrote:
>> >
>> > > With regards to a new version of keycloak.js the question comes up if
>> > > AppAuth-JS [1] can be used instead.
>> > >
>> > > [1] https://github.com/openid/AppAuth-JS
>> > >
>> > > On Tue, 26 Nov 2019 at 16:09, Stian Thorgersen
<sthorger(a)redhat.com>
>> > > wrote:
>> > >
>> > > > keycloak.js doesn't have to be in the same repository to make
sure
>> it
>> > is
>> > > > compatible or release at the same time. Just look at the Node.js
>> > adapter
>> > > > for example.
>> > > >
>> > > > If we want to rewrite keycloak.js using modern approaches and
>> clean it
>> > > up.
>> > > > I would introduce a new repository with a new version of
>> keycloak.js
>> > that
>> > > > doesn't have to worry about backwards compatibility. That can
also
>> be
>> > > > tested using modern JS test tools.
>> > > >
>> > > > That way we can maintain/deprecate the old keycloak.js and
>> eventually
>> > > > replace it with the new modern version.
>> > > >
>> > > > In the future we should also not have a dependency on keycloak.js
>> in
>> > our
>> > > > admin console and new account console. Basically best practices
>> state
>> > > that
>> > > > if you have both SPA and REST APIs on the same domain use cookies
>> and
>> > > > confidential clients, not tokens in the browser and public
clients.
>> > > >
>> > > > On Tue, 26 Nov 2019 at 13:34, Stan Silvert
<ssilvert(a)redhat.com>
>> > wrote:
>> > > >
>> > > >> On 11/26/2019 5:03 AM, Armin Roșu wrote:
>> > > >> > Hello,
>> > > >> >
>> > > >> > We were having a discussion about unit testing
keycloak-js in
>> this
>> > PR:
>> > > >> > https://github.com/keycloak/keycloak/pull/5946 (closed).
>> > > >> >
>> > > >> > An easy way would be to extract it into a separate
repository
>> and
>> > > write
>> > > >> > unit tests there.This would bring further benefits:
>> > > >> There are advantages and disadvantages to putting keycloak-js
in a
>> > > >> separate repo.
>> > > >>
>> > > >> The main advantage I see for having it in the same repo with
>> Keycloak
>> > > >> server is that keycloak.js version is always synced with the
>> Keycloak
>> > > >> server version. For any client/server system there are
always
>> nasty
>> > > >> issues that crop up when client and server versions diverge.
>> > > >> >
>> > > >> > - keycloak.js can be refactored to Typescript
>> > > >> There are definite advantages in code quality when you use
>> TypeScript.
>> > > >> This is both in the maintainability of the source code and
the
>> quality
>> > > >> of the generated keycloak.js file. If we know there are
dedicated
>> > > >> resources to develop the Typescript version and the
associated
>> test
>> > > >> suite then I'm all for it. But that might be a big
"if".
>> > > >> > - file can be split in multiple modules
>> > > >> > - independent versioning from keycloak/keycloak would
enable
>> > > deprecating
>> > > >> > legacy Promises by enabling developers to use the
keycloak-js
>> > version
>> > > >> that
>> > > >> > works for them
>> > > >> > - keycloak-js-bower could also be deprecated.
>> > > >> >
>> > > >> > Guillaume Vincent previously proposed rewriting the
Javascript
>> > > Adapter (
>> > > >> >
>> > > >>
>> > >
>> >
>> https://lists.jboss.org/pipermail/keycloak-dev/2019-September/012457.html
>> > > >> ).
>> > > >> > Extracting it, writing tests for it and rewriting it
afterwords
>> is
>> > an
>> > > >> > option less prone to breaking changes.
>> > > >> >
>> > > >> >
>> > > >> > I have some free time and could start work on this.
>> > > >> >
>> > > >> > What do you think? Should I set up a repo so we can talk
over
>> code?
>> > > >> >
>> > > >> > Cheers,
>> > > >> > Armin
>> > > >> > _______________________________________________
>> > > >> > keycloak-dev mailing list
>> > > >> > keycloak-dev(a)lists.jboss.org
>> > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > > >>
>> > > >>
>> > > >> _______________________________________________
>> > > >> keycloak-dev mailing list
>> > > >> keycloak-dev(a)lists.jboss.org
>> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > > >
>> > > >
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> --
>>
>> Guillaume Vincent
>>
>> Senior Software Engineer
>>
>> Red Hat <https://www.redhat.com>
>> <https://www.redhat.com>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
1849
days inactive
1852
days old
8 comments
6 participants
participants (6)
-
Armin Roșu -
Guillaume Vincent -
Jon Koops -
Michal Hajas -
Stan Silvert -
Stian Thorgersen