Do you think it would make sense to skip detect-browser javascripts when someone uses
https://sitename.com/user-api-key/new
endpoint? They are most likely being redirected there from an app, so checking if their javascript engine is up to snuff makes little sense and only blocks users that want to generate an api key for in-app usage
But you still need to log in for it to work
Yeah that’s the problem, when user-api-key/new redirects you to a login page it then starts checking your browser and instead of allowing login to generate api key, it complains about your browser being too old, maybe skip those checks if user is here only to generate an api key?
Yeah that is the issue, it’s kind of asking for a JavaScript less way of logging in, this is incredibly complex given the enormous amount off auth options we support and spam prevention measures
Doesn’t need to be javascriptless, just login forms don’t really need all the bells and whistles that are used elsewhere on the site? At least for passthrough to the auth/oauth2_basic doesn’t seem to be needed as 99% is done with headers and redirects. I have an app on SailfishOS that works completely fine with the .json’s and passing the api-key, which is great as the browser there is esr78 firefox based and gets blocked in most discourse instances, but the only way to get an api-key seems to be manually entering 200+ char URL in desktop, then pasting the resulting code back on the phone to decode it, absolutely ridiculous