will do 👍. I saw the notice about the json file but decided to add the translations to the "old" location because I reuse some of the existing oauth translations in the new templates.
thanks! I saw require.NoError but missed that it returns a bool allowing to abort the test on error
ooh, nice! I'll remember that for other projects :)
thanks, good catch! I misremembered the blog posts around the math/rand/v2 release saying that v2 was ok to use for this. In fact, they just say it's "not catastrophic anymore" 🤦.
DeviceCode and UserCode are temporary credentials that the device_authorization endpoint issues to the oauth client application. The application then prompts the user to visit the verificatio...
I also noticed there's a similar PR for gitea here: https://github.com/go-gitea/gitea/pull/35379. Since gitea is MIT licensed, we could also adopt that. Some differences from my approach:
if a client requests a device authorization but stops polling for it (i.e. because the user hit ctrl-c), we never clean up expired authorizations. Does Forgejo have some kind of cron/job-scheduling...
Should DeviceCode and/or UserCode be hashed in the DB?
I'm a bit shaky on web security: does the authorization flow need some kind of additional CSRF protection?
maybe only display this if the user arrived here via direct link? I imagine the wording would be something along the lines of "ensure the code {{.UserCode}} matches the one displayed on your...
nit: type="hidden"
again, do we need to validate Scope somehow? What are valid scopes?
the spec recommends ensuring that clients actually respect the authorization.Interval, and reserves an error code for it. Should an a last-seen timestamp and check+update it on every request?
comment can go away: rate limiting is on the token endpoint, not this one. Though maybe rate-limiting this by clientID could make sense? Not sure if there's support in Forgejo 🤔