NCEAS / metacatui

MetacatUI: A client-side web interface for DataONE data repositories
https://nceas.github.io/metacatui
Apache License 2.0
42 stars 27 forks source link

ORCID login issue using IE 11 on Windows 10 #504

Closed vlraymond closed 4 years ago

vlraymond commented 6 years ago

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.

screenshot

vlraymond commented 6 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.

laurenwalker commented 6 years ago

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?

amoeba commented 6 years ago

I see this bug on IE 11 with a fresh Win 10 install.

laurenwalker commented 6 years ago

@amoeba - Thanks Bryce. Do you see any errors in the console or notice any weird IE security settings?

amoeba commented 6 years ago

Hey @laurenwalker I just ran through it and I get two errors:

screen shot 2018-03-13 at 11 21 45 am

I'm uploading a screencast to Drive showing what I see and I'll link that shortly.

amoeba commented 6 years ago

screencast: https://drive.google.com/open?id=1Eu7eJo0L6Bt0mcHGP6WewZCTFi_mikiF

Looks like this may relate to an IE-specific CORS behavior?

ThomasThelen commented 6 years ago

It looks like IE implements an old CORS standard https://stackoverflow.com/questions/36448574/ajax-request-with-cors-redirect-fails-in-ie11

laurenwalker commented 6 years ago

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.

amoeba commented 6 years ago

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.

amoeba commented 4 years ago

Huh. I ran into this issue today and, when I went to look into it, it magically fixed itself.

amoeba commented 4 years ago

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.

laurenwalker commented 4 years ago

Related to #1311

laurenwalker commented 4 years ago

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.