Closed johanstokking closed 4 weeks ago
Hi @johanstokking ,
Can you please provide more details? What do you think, where should we map the error codes?
There is already a mapping here https://github.com/TheThingsNetwork/lorawan-stack/blob/b68c7e9dd4eeb410cfdd98fcc3afba8a11fdce44/pkg/deviceclaimingserver/enddevices/ttjsv2/ttjs.go#L178 Do you think we should change the mapping here? e.g http.StatusForbidden -> errBadRequest
Yes exactly.
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