Open
Conversation
… is not confirmed yet. `403 Forbidden` and `500 Internal server error` responses are handled for loading users on a Map and loading threads of Messages. Accordingly `access_denied` and `internal_server_error` strings are added to the resources.
… is not confirmed yet. `403 Forbidden` and `500 Internal server error` responses are handled for searching for users.
…icable. This way HttpErrorHelper can differentiate exception handling behaviour based on the exception type.
…ad_create_failed and messages_reload_failed)
…t they were doing so instead of simple failure message may be more interested in what actually went wrong. Remove message_send_failed from the resources as it is not used anywhere any more.
Closed
Collaborator
Author
|
Looks like currently there is an extra step in the account creation process, after user confirms his e-mail address there are 3 extra days s/he has to wait until they can send messages. From verification e-mail:
When verified user tries to send anything before this waiting period passes, server returns 403 response. It is handled same as access denied for unverified user, same message is displayed. On the website there is no Send Message button until it is possible to do so. |
5f99b11 to
4cf4e33
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When user creates an account the e-mail address they provided needs to be verified. Util they confirm, they can log in but they don't have access to most resources so the server returns 403 errors. I changed the code so that they get a message with some hints what is going on. This solves #327.
I tried (quite hard) to write tests for my changes, temporarily gave up though. I hope to come back to it later, by the time please give a look at what I have so far.
It is possible to send requests resulting in 403 when loading users to the Map, Searching for specific users or checking Messages. I updated all these places. I thought also that instead we might send a permissions-verifying request first, when user tries to log in (seems for me more intuitive to fail before going further).
I added filtering to exception handling. It is based on http error codes, so that:
403 Forbiddenresponse results in returningaccess_deniedstring from the resources (added), mapped toAccess denied. Please check your email for account confirmation message. (proposition)
500 Internal server errorresponse results in returninginternal_server_errorstring (added), mapped toOops... This is on us, sorry! Something has gone wrong on the server side. Please try again later.
Also:
message_thread_create_failed,messages_reload_failedandmessage_send_failedare not used anywhere any more so I removed themI was thinking of changing error handling, moving towards having one place where different exception types and http error codes are translated to messages and then displayed, so that it is more uniform across the app and we could easily hook some more robust logging/analytics. It's in
HttpErrorHelperas for now. I also narrowed downErrors toHttpExceptions orExceptions so we could differentiate exception handling behavior based on ex type and error code.