Closed vlraymond closed 4 years ago
no change in behavior.
The page got hung up, went to the "Loading" screen, and then reverted to back to the page that says "Sign in to submit data"
On the same Win10 machine I had no issue signing in using Chrome.
Hmm, there must be some security settings in your IE that is preventing login. I have tried to reproduce this error and can't. Has anyone else experienced this in IE 11?
@csjx - Could you try logging in on IE 11 on Windows 10 and see if it works for you?
I see this bug on IE 11 with a fresh Win 10 install.
@amoeba - Thanks Bryce. Do you see any errors in the console or notice any weird IE security settings?
Hey @laurenwalker I just ran through it and I get two errors:
I'm uploading a screencast to Drive showing what I see and I'll link that shortly.
screencast: https://drive.google.com/open?id=1Eu7eJo0L6Bt0mcHGP6WewZCTFi_mikiF
Looks like this may relate to an IE-specific CORS behavior?
It looks like IE implements an old CORS standard https://stackoverflow.com/questions/36448574/ajax-request-with-cors-redirect-fails-in-ie11
I am still unable to reproduce this issue.
The error that Bryce screenshot above is happening on my Windows 10 machine too, but those are from the CORS requests for XML content, which we have known as an issue for quite some time (see this ticket from 3 years ago: https://projects.ecoinformatics.org/ecoinfo/issues/6780).
But logging in always works for me. Because we haven't had any users notify us of failed login attempts and Microsoft is pushing their Windows 10 users towards using Edge, then I am going to put this issue in the backlog, unless someone who can actually reproduce this error could help me out and debug and fix it for me. At this point, I've spent at least two full work days trying to reproduce it.
But logging in always works for me
Even weirder. Given how weird this bug is and that it only affects some IE11 users and that it might have to do with limitations in how we do auth (d1 portal, orcid) that we are not likely to change, backlogging this seems pretty reasonable.
Huh. I ran into this issue today and, when I went to look into it, it magically fixed itself.
I was able to reproduce this finally. I can't say if this was @vlraymond 's issue but it produced the same result: The login flow appears to succeed but I end up where I came from not logged in.
What I saw was that the XHR request MetacatUI sends to the CN /portal/token
endpoint was not sending a cookie (which it needs to) while visiting the /portal/token
endpoint directly did. I then saw that the request was actually being served from cache. So I checked IE11's option to force loading all requests from the server and I was able to log in. I then tested un-setting the option and was still able to successfully log out and back in so it appears this is a one-time state the user can get into but they can get out of it permanently.
My guess is that the response from /portal/token
was being considered cacheable by IE11 but for some reason isn't. We don't set cache-control
or an ETag on the response so maybe we should.
For now, users experiencing this should be able to follow the steps above.
Related to #1311
I think this issue may have been solved in #1311, although I haven't been able to reproduce the bug in my Windows machine, so I can't test for sure. We've decided to deprecate support for IE 11 anyway, so I will close this issue.
When I click the "Submit Data" button and follow the prompt to sign in to ORCID, the system thinks for a second (going for a second to url: cn-stage.test.arcticdata.io) and then returns to the sign-in screen (https://test.arcticdata.io/#submit) I am never able to complete the login process to ORCID.
Screenshot attached. doesn't show much, mainly added it for sharing IE version info.