[keycloak-dev] Extract Javascript Adapter into separate keycloak-js repository

Stian Thorgersen sthorger at redhat.com
Fri Nov 29 09:36:56 EST 2019 

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>> > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > > >>
>>> > > >>
>>> > > >> _______________________________________________
>>> > > >> keycloak-dev mailing list
>>> > > >> keycloak-dev at lists.jboss.org
>>> > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > > >
>>> > > >
>>> > > _______________________________________________
>>> > > keycloak-dev mailing list
>>> > > keycloak-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>

More information about the keycloak-dev mailing list