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

[Sebastien Blanc]

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