<div dir="ltr">Hi Bill, <div>When testing my app with the javascript adapter I have noticed that keycloak.js gets confused when messages other than keycloak's get posted on the window (from same origin). I made a quick fix by adding a type="keycloak" to the data posted to the iframe and checking for that value when the iframe sends it back. Other than that the adapter appears to work just fine. Thanks again for pointing me in the right direction.</div><div>Br / Hubert.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 11:49 PM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<span class=""><br>
<br>
On 1/7/2015 5:25 PM, Hubert Przybysz wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Thanks for the heads-up. I'll take a closer look at the javascript adapter.<br>
<br>
FYI, I've found the k_query_bearer_token request quite useful for a web<br>
app that uses a mix of server-side and javascript components.<br>
<br>
On Wed, Jan 7, 2015 at 4:00 PM, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br></span><span class="">
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>> wrote:<br>
<br>
You probably should not be using the k_query_bearer_token request.<br>
I'm thinking of removing it because it is vulnerable to CSRF<br>
attacks. Instead use keycloak.js for javascript apps.<br>
<br>
On 1/7/2015 9:29 AM, Hubert Przybysz wrote:<br>
<br>
The token is indeed updated automatically when it is requested.<br>
I was<br>
rather wondering if there was a way to not have to request it<br>
prior to<br>
each AJAX request. Currently, since the application does not<br>
know when<br>
the token expires, it has to either get it prior to each AJAX<br>
request,<br>
or try to use a possibly stale token and request it again when<br>
it gets a<br>
401 from the REST service. It would be nice to get information about<br>
token expiry together with the token in response to<br>
k_query_bearer_token<br>
request.<br>
<br>
On Wed, Jan 7, 2015 at 3:11 PM, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br>
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>><br></span><span class="">
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>>> wrote:<br>
<br>
IIRC, if you're using the correct APIs (in Javascript or on<br>
the server<br>
side), the token will be automatically updated for you when you<br>
request it.<br>
<br>
On 1/7/2015 4:06 AM, Hubert Przybysz wrote:<br>
> Hi,<br>
><br>
> My jee web application uses its bearer token when<br>
issuing AJAX<br>
requests<br>
> to other REST services within the realm (but at different<br>
origins). It<br>
> does it by reading the exposed bearer token prior to<br>
making an AJAX<br>
> request. Is there a mechanism by which the application<br>
may find<br>
out when<br>
> the bearer token is refreshed, to make it possible to<br>
read the bearer<br>
> token only when needed ?<br>
><br>
> Br / Hubert.<br>
><br>
><br></span>
> ______________________________<u></u>___________________<span class=""><br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.<u></u>jboss.org</a>><br></span>
<mailto:<a href="mailto:keycloak-user@lists." target="_blank">keycloak-user@lists.</a>__<a href="http://jboss.org" target="_blank"><u></u>jboss.org</a><br>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.<u></u>jboss.org</a>>><br>
> <a href="https://lists.jboss.org/__mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/__<u></u>mailman/listinfo/keycloak-user</a><span class=""><br>
<<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/keycloak-user</a><u></u>><br>
><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br></span>
______________________________<u></u>___________________<span class=""><br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.<u></u>jboss.org</a>><br></span>
<mailto:<a href="mailto:keycloak-user@lists." target="_blank">keycloak-user@lists.</a>__<a href="http://jboss.org" target="_blank"><u></u>jboss.org</a><br>
<mailto:<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.<u></u>jboss.org</a>>><br>
<a href="https://lists.jboss.org/__mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/__<u></u>mailman/listinfo/keycloak-user</a><span class=""><br>
<<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/keycloak-user</a><u></u>><br>
<br>
<br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
<br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
</div></div></blockquote></div><br></div>