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(a)redhat.com&gt; Sent: 25 March 2019 10:34 To: Raul Fechete <rfechete(a)grid-applications.com>; keycloak userlist <keycloak-user(a)lists.jboss.org&gt; 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@grid-applications.com<mailto:rfechete@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/a... 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@redhat.com<mailto:sblanc@redhat.com>> Sent: 21 March 2019 17:45 To: Raul Fechete <rfechete@grid-applications.com<mailto:rfechete@grid-applications.com>> Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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@grid-applications.com<mailto:rfechete@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@lists.jboss.org<mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user

Ok.. Which adapter are you using? Is there any way you could post maybe a screenshot of the communication between browser / adapter / kc? It might help to see if the adapter in your setup responds differently to the client’s POST request than in my case. Just to be sure – your client does a POST on the AS, receives a 302 and then does a GET on KC? Thanks! From: Sebastien Blanc <sblanc(a)redhat.com&gt; Sent: 25 March 2019 11:42 To: Raul Fechete <rfechete(a)grid-applications.com&gt; Cc: keycloak userlist <keycloak-user(a)lists.jboss.org&gt; Subject: Re: [keycloak-user] KeyCloak Server and HTTP OPTIONS (JSF/Primefaces behind KC Adapter) 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@grid-applications.com<mailto:rfechete@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@redhat.com<mailto:sblanc@redhat.com>> Sent: 25 March 2019 10:34 To: Raul Fechete <rfechete@grid-applications.com<mailto:rfechete@grid-applications.com>>; keycloak userlist <keycloak-user@lists.jboss.org<mailto:keycloak-user@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@grid-applications.com<mailto:rfechete@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/a... 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@redhat.com<mailto:sblanc@redhat.com>> Sent: 21 March 2019 17:45 To: Raul Fechete <rfechete@grid-applications.com<mailto:rfechete@grid-applications.com>> Cc: keycloak-user@lists.jboss.org<mailto:keycloak-user@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@grid-applications.com<mailto:rfechete@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@lists.jboss.org<mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user