Hi, Nick. It works for me both in Chrome and in Firefox. The ticket you referenced actually provides a useful suggestion, to open `https://your.host.loc/` url in your browser. You shouldn't try to open `https://your.host.loc/oxauth/login` right away, for example. Other that, or something is broken in your environment (not Gluu-related)

Hi, Aliaksandr. Thank you for your reply. I did notice the recommendation in that ticket, and I receive the same error even when I go to https://gluu.test (my test virtual machine). I have my oxAuth logging level set to ALL. Is there anything else I could do within Gluu to get a better idea of what it doesn't like about what Firefox and Safari are sending it? Thanks, Nick

Nothing comes to mind. Have you tried to clear cookies/local storages in your browser, disabling any kind of "Incognito" modes or plug-ins which may meddle with page's contents? Trying it in a clean, fresh Firefox instance, in the end? If nothing of this helps, please try to spin-up a new Gluu instance in a different similar vm, see if it can be reproduced. What is your exact package version? Please run `# rpm -qia '*gluu-server*'`

Hi, Aliaksandr. Thanks again for your reply. I have tried clearing cookies, cache, etc. in the browser, removed all of my add-ons/plugins, and am still seeing the same. I am not in a spot to install a brand new Firefox, but I will give that a shot. I just downloaded and tried Opera, and it does work properly. It just kind of bugs me that both Firefox and Safari are behaving the same way. In any event, for reference, the RPM package output is below: ``` Name : gluu-server-3.1.2 Version : 1 Release : 4.centos7 Architecture: x86_64 Install Date: Wed 07 Mar 2018 10:34:54 PM UTC Group : Gluu Size : 1415527075 License : MIT Signature : RSA/SHA256, Fri 19 Jan 2018 04:15:41 PM UTC, Key ID 5b76117e0544ba38 Source RPM : gluu-server-3.1.2-1-4.centos7.src.rpm Build Date : Fri 19 Jan 2018 03:56:18 PM UTC Build Host : pkg-rpm2.gluu.org Relocations : (not relocatable) Packager : Gluu support <support@gluu.org> Vendor : Gluu, Inc. Summary : Gluu chroot CE environment Description : Gluu base deployment for CE ``` At this point, we can probably assume it is, indeed, something with my environment, so we can go ahead and close the ticket. If I am able to identify what's happening, or if I find that re-installing my browser resolves the issue, I'll update the ticket to help those who might run into the same thing in the future. Thanks, Nick

Thanks, Nick. Please do..

Hello. I wanted to re-open this ticket. I deployed a new Gluu server on a public server, and all appeared fine. We have recently begun to have a few preliminary users access the system as we prepare for a production deployment. One of our users is now experiencing the same thing I described previously, only he is using Postman (OAuth 2 authorization) and getting the same error loop. Strangely, as happened to me, this worked for him previously and has suddenly begun to error out as of this morning. There were no configuration changes in the Gluu server. It almost seems like there is something about specific user sessions being cached somewhere. Any help/thoughts/insight would, again, be much appreciated!

Hi, Nick. Please provide exact HTTP request which you send using Postman and which results in this outcome. Is this user able to reproduce this behaviour in a regular browser? Please also note that we usually are reluctant in supporting any non-standard usage practices within the scope of Community Support, which includes using low-level tools like Postman. Please try to devise a detailed steps to reproduce it in a regular browser for us to have something we can reliable work with.

Hi, Aliaksandr. Sorry for the delay. Our user reported that the issue went away on its own yesterday morning. However, yesterday afternoon, I began to experience the same behavior in Chrome. So, I've been able to gather a bit more information. I am redirected to the error page when I, ultimately, attempt to access /oxauth/login (via the primary FQDN - in other words, I know I can't navigate directly to /oxauth/login and expect it to work). I have noticed something bizarre in the attempts that yield this error: it appears the browser is sending duplicate cookies - 2 for session_id and 2 for session_state. The request headers are below, with FQDN removed: ``` GET /oxauth/login HTTP/1.1 Host: <GLUU-HOST-FQDN> Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Referer: https://<GLUU-HOST-FQDN>/identity/ Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9 Cookie: org.gluu.i18n.Locale=en; session_id=ac717541-4d84-43d7-b68a-42d5e2179dfd; session_state=f7867b3b-c320-48b7-99da-c81e46a30ebb; csfcfc=%2BxLXY6YhfQ%3D%3D; org.gluu.i18n.Locale=en; session_id=b5c4d6dd-6291-4e7d-bec3-4e8e80e6a15e; session_state=cf495ddc-b0fa-47b9-bb56-16c663cda278 ``` When I examine the cookies in my Chrome browser, I see that I have a session_id with a path of "/" and another with a path of "/oxauth," which I believe is why the browser is sending both. I have three cookies for session_state, with different paths: "/", "/oxauth", and "/oxauth/restv1". Here is what I find for both in my browser's cookie list: ``` session_id Name session_id Content f487ad86-bc94-4140-99e1-77d5be69b4a6 Domain <GLUU-HOST-FQDN> Path / Send for Secure connections only Accessible to script No (HttpOnly) Created Thursday, April 19, 2018 at 5:32:17 PM Expires Friday, April 20, 2018 at 5:32:18 PM session_id Name session_id Content ac717541-4d84-43d7-b68a-42d5e2179dfd Domain <GLUU-HOST-FQDN> Path /oxauth Send for Any kind of connection Accessible to script Yes Created Wednesday, April 18, 2018 at 5:13:31 PM Expires When the browsing session ends session_state Name session_state Content cb3af992-a735-4e9d-a50f-e2125b266ce9 Domain <GLUU-HOST-FQDN> Path / Send for Secure connections only Accessible to script Yes Created Thursday, April 19, 2018 at 5:32:17 PM Expires Friday, April 20, 2018 at 5:32:18 PM session_state Name session_state Content f7867b3b-c320-48b7-99da-c81e46a30ebb Domain <GLUU-HOST-FQDN> Path /oxauth Send for Any kind of connection Accessible to script Yes Created Wednesday, April 18, 2018 at 5:13:31 PM Expires When the browsing session ends session_state Name session_state Content 3c54aa44-c829-4d52-9788-596389d68aad Domain <GLUU-HOST-FQDN> Path /oxauth/restv1 Send for Any kind of connection Accessible to script Yes Created Wednesday, April 18, 2018 at 5:13:16 PM Expires When the browsing session ends ``` From looking through the Gluu source code a bit, it seems that the shortest path to the error in the oxauth logs ("Failed to get attributes from session" in org.xdi.oxauth.auth.Authenticator) would be some kind of an issue getting the session ID from a cookie. So, I am thinking that the issue may be due to cookies not being disposed of by browsers when they should, then sending two when oxAuth expects only one. The odd thing, though, is, when I previously experienced this behavior with Firefox and Safari, I certainly did clear my cookies, history, etc., and the problem remained. I'll continue investigating. I'll clear my cookies on this browser and see if the issue goes away. But, I wanted to document what I've found in case you have any thoughts, as well as to maybe point others in a direction if they encounter this as well. Thanks.

OK, I've got a bit more information. When I enabled all logging in oxAuth, I noticed that oxAuth repeatedly tried to find a session based on the first session_id it found. As a result, I copied the request from Chrome as a cURL command, then sent it via cURL minus the initial session_id and session_state, and cURL received the login page as expected. It looks like getSessionIdFromCookie(HttpServletRequest request, String cookieName) in SessionIdService returns the first session_id cookie it finds. Now, to figure out why we're getting duplicates... For what it's worth, we have custom-skinned the oxauth/login page and the oxauth/error page. I doubt that would impact cookie generation, but it's a difference from the standard Gluu deployment.