[keycloak-user] KeyCloak Server and HTTP OPTIONS (JSF/Primefaces behind KC Adapter)

[Sebastien Blanc]

I just tried with a POST (both after a logout due to timout + plus kc
intiiated logout) and it is behaving as expected (no OPTIONS call) ...
Maybe it's related to EAP/EAP Adapter ...


On Mon, Mar 25, 2019 at 10:53 AM Raul Fechete <
rfechete at grid-applications.com> wrote:

> Is your browser (JSP webseite) doing a POST call towards the application
> server?
>
>
>
> The login flow works fine as long as the browser is doing a GET. From what
> I understand, in this case the browser is trying to do a POST towards the
> application server and gets redirected towards KC by the adapter and since
> a **POST** was redirected, it then first tries an OPTIONS on the KC
> (maybe to see if it should also try a POST on the KC?).
>
>
>
> I did a replay on the redirect answer from the adapter using GET instead
> of OPTIONS, and it does work.
>
>
>
> Also, I tried the auth flow with both the current Firefox and Chrome
> browser and it’s the same: browser calls POST on the AS -> Adapter replies
> with 302 Redirect -> browser calls OPTIONS on the KC.
>
>
>
> This is really weird. I can’t be the only one with a JSF website behind
> the KC adapter, whose sessions ran out.
>
>
>
> *From:* Sebastien Blanc <sblanc at redhat.com>
> *Sent:* 25 March 2019 10:34
> *To:* Raul Fechete <rfechete at grid-applications.com>; keycloak userlist <
> keycloak-user at lists.jboss.org>
> *Subject:* Re: [keycloak-user] KeyCloak Server and HTTP OPTIONS
> (JSF/Primefaces behind KC Adapter)
>
>
>
> Indeed it's weird that it tries to do an OPTIONS. I just tried with a
> simple JSP app with WF 15 and the WF Elytron adapter and I can not
> reproduce it.
>
> Maybe the best is to open a ticket and also add a reproducer.
>
> Also instead of using + or * , could you try by entering the entire domain
> name like "http://localhost:8080" ?
>
>
>
>
>
>
>
>
>
> On Mon, Mar 25, 2019 at 8:29 AM Raul Fechete <
> rfechete at grid-applications.com> wrote:
>
> Yes I have (both * and +), but it makes no difference. Making a HTTP
> OPTIONS call on KeyCloak always returns 204 No Content, regardless of the
> URL I’m using. I can even manually call OPTIONS on
> http://localhost:8180/auth/admin/master/console, which has nothing to do
> with the authentication flow and the answer is still 204.
>
>
>
> The URL used during the authentication flow is:
>
>
>
>
> http://localhost:8180/auth/realms/<REALM>/protocol/openid-connect/auth?response_type=code&client_id=<CLIENT_ID>&redirect_uri=<URL>&state=c01faac4-d083-401f-b906-b8b775297ee2&login=true&scope=openid
>
>
>
> This URL works perfectly fine when the browser uses GET, but returns 204
> when the browser uses OPTIONS.. After the 204, the browser just doesn’t do
> anything else.
>
>
>
> Am I missing something?
>
>
>
> Thank you very much!
>
>
>
> *From:* Sebastien Blanc <sblanc at redhat.com>
> *Sent:* 21 March 2019 17:45
> *To:* Raul Fechete <rfechete at grid-applications.com>
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] KeyCloak Server and HTTP OPTIONS
> (JSF/Primefaces behind KC Adapter)
>
>
>
> Have you put a value for the Web Origin property in the client
> configuration on the KC Console ?
>
>
>
> On Thu, Mar 21, 2019 at 12:46 PM Raul Fechete <
> rfechete at grid-applications.com> wrote:
>
> Hello,
>
> I'm trying to build what should be a trivial setup, but I'm having trouble
> getting to work properly.
>
> I have a JSF Application running on JBoss EAP 7.2, secured by the KC Java
> Adapter. The initial login flow works perfectly fine (browser asks for
> website, adapter intercepts and redirects to KC, user logs in with KC and
> is being redirected back to the website).
>
> Now, the JSF application often uses POST requests. If the user has been
> logged out (e.g. in KC directly), clicking anywhere on the website triggers
> a POST request to the application, which is being intercepted by the KC
> Adapter and redirected (302) to KC. This would be fine, but the problem is,
> the browser then performs a HTTP *OPTIONS* call to KC instead of HTTP GET,
> and the KC just returns 204 without any further information. I also noticed
> that the KC Server *always* replies with an empty 204 to a HTTP OPTIONS
> call, even if there is nothing else in the request.
>
> Is there any way to configure the handling of the OPTIONS requests in KC?
> Alternatively, is it possible to configure the adapter to send a 303 and
> thereby force the browser to perform a GET request? Or am I doing something
> conceptually wrong?
>
> Any help would be appreciated!
> Thank you very much!
>
> Cheers, Raul
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>