Skip to content

Display errors during login #1689

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 21, 2019
Merged

Conversation

sgrif
Copy link
Contributor

@sgrif sgrif commented Mar 21, 2019

The code was serializing an entire response object, which didn't
actually contain the errors that came back from the API, so we'd never
show anything other than "Failed to log in". With this change we now
show the error returned by the API if it returned any. Notably, if a
user tries to create a new account while we're in read only mode, they
will now see an error saying that.

The code was serializing an entire response object, which didn't
actually contain the errors that came back from the API, so we'd never
show anything other than "Failed to log in". With this change we now
show the error returned by the API if it returned any. Notably, if a
user tries to create a new account while we're in read only mode, they
will now see an error saying that.
@sgrif sgrif requested a review from jtgeibel March 21, 2019 18:47
sgrif added a commit to sgrif/crates.io that referenced this pull request Mar 21, 2019
Currently whenever a user signs in we attempt to update their profile
(display name, avatar, email, etc). If we're in read only mode, we can't
do that. However, preventing them from signing in entirely seems
unfortunate.

If we get a read-only error, we will now try to look for an existing
user, returning that user if found (or any errors that occurred loading
it), and continue to return `ReadOnlyMode` if we couldn't find an
existing user.

A user will have to sign out and back in again after maintenance has
completed if they want to update their information. Ideally we'd display
a warning informing them of this fact, but we don't currently have code
in place to support that, and with < 3 hours remaining until maintenance
time, there's not enough time to write it.

I'd also love to add some explicit tests for this, but none of our
existing tests handle GitHub oauth, and again, there's not enough time
for me to figure out what our recordings need to look like for that.

If we're not comfortable shipping this in this imperfect state (no
warning, no tests), then we should just close this, and folks won't be
able to log in during the maintenance period. That's not the end of the
world. However, I've tested this locally to make sure it behaves
properly (with rust-lang#1689 as well to make sure we display the right error),
so I'd like to ship this to minimize disruption during the DB
maintenance
@jtgeibel
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Mar 21, 2019

📌 Commit e8f7bde has been approved by jtgeibel

bors added a commit that referenced this pull request Mar 21, 2019
Display errors during login

The code was serializing an entire response object, which didn't
actually contain the errors that came back from the API, so we'd never
show anything other than "Failed to log in". With this change we now
show the error returned by the API if it returned any. Notably, if a
user tries to create a new account while we're in read only mode, they
will now see an error saying that.
@bors
Copy link
Contributor

bors commented Mar 21, 2019

⌛ Testing commit e8f7bde with merge 67d178a...

@bors
Copy link
Contributor

bors commented Mar 21, 2019

☀️ Test successful - checks-travis
Approved by: jtgeibel
Pushing 67d178a to master...

@bors bors merged commit e8f7bde into rust-lang:master Mar 21, 2019
bors added a commit that referenced this pull request Mar 21, 2019
Allow existing users to sign in while READ_ONLY_MODE=1

Currently whenever a user signs in we attempt to update their profile
(display name, avatar, email, etc). If we're in read only mode, we can't
do that. However, preventing them from signing in entirely seems
unfortunate.

If we get a read-only error, we will now try to look for an existing
user, returning that user if found (or any errors that occurred loading
it), and continue to return `ReadOnlyMode` if we couldn't find an
existing user.

A user will have to sign out and back in again after maintenance has
completed if they want to update their information. Ideally we'd display
a warning informing them of this fact, but we don't currently have code
in place to support that, and with < 3 hours remaining until maintenance
time, there's not enough time to write it.

I'd also love to add some explicit tests for this, but none of our
existing tests handle GitHub oauth, and again, there's not enough time
for me to figure out what our recordings need to look like for that.

If we're not comfortable shipping this in this imperfect state (no
warning, no tests), then we should just close this, and folks won't be
able to log in during the maintenance period. That's not the end of the
world. However, I've tested this locally to make sure it behaves
properly (with #1689 as well to make sure we display the right error),
so I'd like to ship this to minimize disruption during the DB
maintenance
@sgrif sgrif deleted the sg-display-login-errors branch March 25, 2019 21:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants