Hi Thomas (and others),
Thanks for your time. What you are describing is my plan B (a shared Keycloak instance
running to which all developers can connect), but as you expected I prefer to not have to
be online nor to run an extra application (Keycloak) every time. 99% of the time a default
user will suffice and will make the development process a lot more lightweight. Other
suggestions are very welcome.
Kind regards,
Martijn
From: Thomas Raehalme [mailto:thomas.raehalme@aitiofinland.com]
Sent: dinsdag 15 maart 2016 16:19
To: Martijn Claus <m.claus(a)smile.nl>
Cc: keycloak-user <keycloak-user(a)lists.jboss.org>
Subject: Re: [keycloak-user] Not using keycloak in development
On Mar 15, 2016 16:57, "Martijn Claus"
<m.claus@smile.nl<mailto:m.claus@smile.nl>> wrote:
I’ve been setting up Keycloak and liking it thus far. We are using it
in an angular / Spring / REST context. For development there are cases where I don’t want
to run the Keycloak application (war) but only my own application. I assume this is a
valid usecase. But if I turn the Keycloak off, the angular frontend will redirect me to an
offline url and the application fails. I will not have a token and the backend will
rightfully throw back some AccessDeniedExceptions. Is there a way to use some kind of
(magic/permanent/development) token that will be accepted by the backend and the Keycloak
application will never have to be contacted? Or is there some other feature that my
backend spring keycloak adapter will accept anything and work with a default user?
I'm not sure what you suspect is possible, but here's what we do:
In development mode we use Keycloak configuration which connects to a shared Keycloak
instance where we have configured a specific realm and client allowing the use of
localhost as redirect URL. This works for every developer and we don't need to
"turn off" authentication.
The downside is that you need to be online. If this is a problem you could always use
Vagrant or Docker to run Keycloak on localhost. But I guess you were trying to avoid
this.
In production we naturally use another Keycloak configuration which we can enable through
Spring profiles or Tomcat context.xml or whatever method best fits the situation.
Hope this helps!
Best regards,
Thomas