Closed mfilej closed 2 years ago
Realistically they're not going to be able to do anything with the information given the strength of the algorithms, but I personally wouldn't do it. I would just throw it in a with statement, and, on exception/error tuple thing, just return "Authorization failed."
A lot of the errors will be impenetrable for the user:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Miha Filej @.***> schrieb am Dienstag, 21. Dezember 2021 um 08:46:
Apologies for opening an issue just for a question.
When using parse_token inside a Plug, I'm wondering whether I need to match on the message returned in an {:error, message} tuple, or is it safe to just forward the message as part of the HTTP response? Would I be giving away too much in this case?
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks for the quick response, I appreaciate your help.
I was being too vague -- in our case the user is a developer coding against our API, so seeing "wrong version" might actually be helpful here. If there are no significant downsides then I'm leaning towards returning the message together with a 401 response.
In either case I'm closing this issue since it was just a question. 🙂
Apologies for opening an issue just for a question.
When using
parse_token
inside a Plug, I'm wondering whether I need to match on themessage
returned in an{:error, message}
tuple, or is it safe to just forward the message as part of the HTTP response? Would I be giving away too much in this case?