If your server-side components are all REST-based, I suggest using bearer token auth for them and obtaining the token via the keycloak.js adapter. Again, k_query_bearer_token auth is vulnerable to CSRF right now.
On 1/7/2015 5:25 PM, Hubert Przybysz wrote:
Thanks for the heads-up. I'll take a closer look at the javascript adapter.
FYI, I've found the k_query_bearer_token request quite useful for a web
app that uses a mix of server-side and javascript components.
On Wed, Jan 7, 2015 at 4:00 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>> wrote:
You probably should not be using the k_query_bearer_token request.
I'm thinking of removing it because it is vulnerable to CSRF
attacks. Instead use keycloak.js for javascript apps.
On 1/7/2015 9:29 AM, Hubert Przybysz wrote:
The token is indeed updated automatically when it is requested.
I was
rather wondering if there was a way to not have to request it
prior to
each AJAX request. Currently, since the application does not
know when
the token expires, it has to either get it prior to each AJAX
request,
or try to use a possibly stale token and request it again when
it gets a
401 from the REST service. It would be nice to get information about
token expiry together with the token in response to
k_query_bearer_token
request.
On Wed, Jan 7, 2015 at 3:11 PM, Bill Burke <bburke@redhat.com
<mailto:bburke@redhat.com>
<mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> wrote:
IIRC, if you're using the correct APIs (in Javascript or on
the server
side), the token will be automatically updated for you when you
request it.
On 1/7/2015 4:06 AM, Hubert Przybysz wrote:
> Hi,
>
> My jee web application uses its bearer token when
issuing AJAX
requests
> to other REST services within the realm (but at different
origins). It
> does it by reading the exposed bearer token prior to
making an AJAX
> request. Is there a mechanism by which the application
may find
out when
> the bearer token is refreshed, to make it possible to
read the bearer
> token only when needed ?
>
> Br / Hubert.
>
>
> _________________________________________________
> keycloak-user mailing list
> keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.__jboss.org
<mailto:keycloak-user@lists.jboss.org>>
> https://lists.jboss.org/__mailman/listinfo/keycloak-user
<https://lists.jboss.org/mailman/listinfo/keycloak-user>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_________________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
<mailto:keycloak-user@lists.__jboss.org
<mailto:keycloak-user@lists.jboss.org>>
https://lists.jboss.org/__mailman/listinfo/keycloak-user
<https://lists.jboss.org/mailman/listinfo/keycloak-user>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com