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

Wed Nov 27 06:24:59 EST 2019

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
>
>