Applying custom login form + css causes form to ignore get client_id

By: Thomas Maerz user 08 Aug 2016 at 5:13 p.m. CDT

4 Responses
Thomas Maerz gravatar
I have adapted a standardized (responsive mobile) login form and CSS to the facelets xhtml template format and eventually gotten it displaying correctly, but when I try to log in through the form on Safari on an iPhone/iPad or Mac it returns ```The request is invalid, please try again```. Digging into the logs reveals errors in oxauth.log: ``` INFO | jvm 1 | 2016/08/08 17:02:35 | Aug 08, 2016 5:02:34 PM com.sun.faces.lifecycle.Phase doPhase INFO | jvm 1 | 2016/08/08 17:02:35 | SEVERE: JSF1054: (Phase ID: APPLY_REQUEST_VALUES 2, View ID: /login.xhtml) Exception thrown during phase execution: javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@1763e2ee] INFO | jvm 1 | 2016/08/08 17:02:35 | 2016-08-08 17:02:35,000 ERROR [org.jboss.seam.exception.Exceptions] handled and logged exception INFO | jvm 1 | 2016/08/08 17:02:35 | javax.servlet.ServletException: viewId: /login.xhtml - No client identifier provided ``` I believe that for some reason, the client_id get in the login form: ```<c:set var="client" value="#{clientService.getClient(sessionAttributes['client_id'])}"/>``` is getting ignored. It seems to work on Chrome and Firefox on any platform (Windows, OSX, Android, iOS) but just not Safari. The only reason this matters is when you open an app that requests SAML login on an iPhone, it directs the SSO page on Safari (no way around this). Is there something I am missing when creating my template? Do I need to put the get client_id c:set statement somewhere else in the form? The default template does not do this when I revert to it. This is my [login.xhtml](http://pastebin.com/raw/f1ZJNBAB) and here is my [css](http://pastebin.com/raw/fZdQjNZ5) Edit: This responsive form actually does it on all browsers. It was initially working for me until I restarted the browsers, so there was probably still an initiated session open that was allowing it to work.
U1404
closed

Answers

By Thomas Maerz user 08 Aug 2016 at 5:37 p.m. CDT

Copy
Thomas Maerz gravatar
Edit: This responsive form actually does it on all browsers. It was initially working for me until I restarted the browsers, so there was probably still an initiated session open that was allowing it to work.

By Aliaksandr Samuseu staff 16 Aug 2016 at 6:58 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Thomas. Despite we've recommended an upgrade to 2.4.4 for you instance, I'm not sure whether it will resolve this issue. It seems more like peculiarities of Safari to me. If you don't mind to dig around a bit, I could propose to capture HTTP requests sent both by browsers that work, and the Safari browser, during the login flow, and compare them, trying to find out what differences are, and whether they conform to some standards. Feel free to share your findings with us, we could think together what to do with it then. Best regards, Alex.

By Aliaksandr Samuseu staff 16 Aug 2016 at 7:02 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Sorry, I had a stale page with this ticket opened. So I missed your addition about all other browsers failing too..

By Aliaksandr Samuseu staff 16 Aug 2016 at 7:07 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Still, have you tried to compare HTTP requests produced both by your (failing) login page, and, say, Gluu's default login page? May I ask you to capture the full (failing) login flow with Firefox browser, and share it with us? You can use any tool of your liking, which can produce output in user-friendly format. EDIT: I mean capture of HTTP interxechange, like with some kind of intercepting proxy, or `mod_dumpio` module for Apache. I believe there are also addons for Firefox capable of this.

Post an answer