You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Things Join Server returns various error codes which The Things Stack should understand better to improve the user experience.
Current Situation
Currently, when the device's claim authentication code (owner token) is wrong, TTJS returns 403 that is passed through to the client (Console), which suggests the user to sign-in again. Instead, this occassion should be mapped to 500 because it is bad configuration.
Why do we need this? Who uses it, and when?
We need not to confuse users to sign in again if server-to-server authentication failed or if a claim code is wrong.
Proposed Implementation
TTJS returns:
401 if not authenticated as an AS = bad config, internal server error
400 if the DevEUI is malformatted = client error, internal server error
400 if the claim request is malformatted = client error, internal server error
403 if the authenticated AS is not the AS in the claim request = client error, internal server error
403 if the owner token is wrong
I.e. TTS cannot simply map a status code to another one, as some are reused (as they should be). Most notably, the last 403 is relevant to the end user, while the others are all bad config and should return 500.
The only way to implement this is to test the error message that TTJS returns. If it is 403 and the message is claim failed with given owner token, it should be mapped to 400 (Bad request) and the others should be 500 (Internal server error).
Contributing
I can help by doing more research.
I can help by implementing the feature after the proposal above is approved.
I can help by testing the feature before it's released.
Summary
The Things Join Server returns various error codes which The Things Stack should understand better to improve the user experience.
Current Situation
Currently, when the device's claim authentication code (owner token) is wrong, TTJS returns 403 that is passed through to the client (Console), which suggests the user to sign-in again. Instead, this occassion should be mapped to 500 because it is bad configuration.
Why do we need this? Who uses it, and when?
We need not to confuse users to sign in again if server-to-server authentication failed or if a claim code is wrong.
Proposed Implementation
TTJS returns:
I.e. TTS cannot simply map a status code to another one, as some are reused (as they should be). Most notably, the last 403 is relevant to the end user, while the others are all bad config and should return 500.
The only way to implement this is to test the error message that TTJS returns. If it is 403 and the message is
claim failed with given owner token
, it should be mapped to 400 (Bad request) and the others should be 500 (Internal server error).Contributing
Validation
Code of Conduct
The text was updated successfully, but these errors were encountered: