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
5 posts were split to a new topic: User API keys should use OAEP padding
Hallo allemaal. Ik gebruikte User API-sleutels voor het inloggen met een externe client. Het werkte altijd prima. Maar nu krijg ik een foutmelding op sommige sites
De melding is
Oeps
De software die dit discussieforum aandrijft, ondervond een onverwacht probleem. Onze excuses voor het ongemak.
Gedetailleerde informatie over de fout is geregistreerd en een automatische melding gegenereerd. We zullen ernaar kijken.
Verdere actie is niet nodig. Als de fouttoestand echter aanhoudt, kunt u aanvullende details verstrekken, inclusief stappen om de fout te reproduceren, door een discussieonderwerp te plaatsen in de feedbackcategorie van de site.
Is er iets veranderd in deze functie in de laatste versies?
Do you mean “logging in”? I think discourse connect is probably a better way to do that, though I don’t know what it is you’re actually doing.
You’ll need to look at the logs to get more information about what the error is.
I’m running a custom UI so I need to perform actions in user behalf. For that Im using User API keys
For that Im using the following url
https://discussion.fedoraproject.org/user-api-key/new?auth_redirect=discourse%3A%2F%2Fauth_redirect&application_name=DisCorkie&client_id=019695ed-8b7e-71b1-b55e-7efe8be1e9ae&scopes=read%2Cwrite%2Cnotifications%2Cpush%2Csession_info&push_url=https%3A%2F%2Fherxbktlunuawewahana.supabase.co%2Ffunctions%2Fv1%2Fdiscourse-webhook&public_key=-----BEGIN+PUBLIC+KEY-----%0AMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkD%2BNgNuAMv2ZSSR95V1B%0Afla9n3HbCPxAFB5%2B%2BitC9hlWEOfXZPToWAax5DuNUitzikLVWrldyRe%2BfgtS5F3Q%0AGvuzCtnFwyBNoIkuUva8uCzQ4K7T9RgnWIIfNsx2ONuk2GLhEeLUgb46F8VULbD3%0A4eExqEYoGK7tBxr3%2FnVYO%2FogOaibzhoZRiSh69gq6ptXWN9Pka%2Fb3%2Fp2hWF5MSwG%0AK39LiZKOzaga%2BsA0lA0BgdAw7rvnUBfpikL33mqtEJ6JDPhG5KIvBxY2m18T63cX%0AKakxrmZzWwibN%2Bzboe51Z49gtxJIiybaj5Yn7izPj39DKwiv5k%2FaSWFAe8FO0doQ%0AxVoh9qVhlvPq3DdLhcjC0djVNti3X%2BYC2bwUDSp%2BFhrLh%2BsYribCAp6P8TyZ5TZy%0Aw0WnDCatK%2FzPq53Fja2OUa5N43Zr4rSiyQMSdBaeOJwF33nOAHwztkDwOJvSh6fx%0Ag2mTR15Qe%2FRh6yY4fB610mcut%2BBU1oV4SEbxHYyroTaS06oO6k4EmvgJTiWK%2BVVC%0AfMGgFvoPXktKckK0q7xj32PiSTVlYURb27ap7yAHzFKePYkJdo0Sd3Jzghe1RdSg%0A4teQs4VecqIe%2Bv6p7BurFgwlKZyWN0n89u8%2BXihwwwOcVp1UHblqbl%2FKYi5%2BgK6O%0AyahsLRGMGllNIsqarYCZ9nkCAwEAAQ%3D%3D%0A-----END+PUBLIC+KEY-----%0A&nonce=-1646128802
Where
PARAMETERS
auth_redirect: discourse://auth_redirect
application_name: DisCorkie
client_id: 019695ed-8b7e-71b1-b55e-7efe8be1e9ae
scopes: read,write,notifications,push,session_info
push_url: https://herxbktlunuawewahana.supabase.co/functions/v1/discourse-webhook
public_key:
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkD+NgNuAMv2ZSSR95V1B
fla9n3HbCPxAFB5++itC9hlWEOfXZPToWAax5DuNUitzikLVWrldyRe+fgtS5F3Q
GvuzCtnFwyBNoIkuUva8uCzQ4K7T9RgnWIIfNsx2ONuk2GLhEeLUgb46F8VULbD3
4eExqEYoGK7tBxr3/nVYO/ogOaibzhoZRiSh69gq6ptXWN9Pka/b3/p2hWF5MSwG
K39LiZKOzaga+sA0lA0BgdAw7rvnUBfpikL33mqtEJ6JDPhG5KIvBxY2m18T63cX
KakxrmZzWwibN+zboe51Z49gtxJIiybaj5Yn7izPj39DKwiv5k/aSWFAe8FO0doQ
xVoh9qVhlvPq3DdLhcjC0djVNti3X+YC2bwUDSp+FhrLh+sYribCAp6P8TyZ5TZy
w0WnDCatK/zPq53Fja2OUa5N43Zr4rSiyQMSdBaeOJwF33nOAHwztkDwOJvSh6fx
g2mTR15Qe/Rh6yY4fB610mcut+BU1oV4SEbxHYyroTaS06oO6k4EmvgJTiWK+VVC
fMGgFvoPXktKckK0q7xj32PiSTVlYURb27ap7yAHzFKePYkJdo0Sd3Jzghe1RdSg
4teQs4VecqIe+v6p7BurFgwlKZyWN0n89u8+XihwwwOcVp1UHblqbl/KYi5+gK6O
yahsLRGMGllNIsqarYCZ9nkCAwEAAQ==
-----END PUBLIC KEY-----
nonce:-1646128802
It redirects to /login, the browser calls /session/csrf successfully, no issue so far.
However, when the browser calls /auth/oauth2_basic I get a 500
The response is this error message and no additional information.
Discourse hub does a similar authentication flow but it works. Is there anything Im missing?
Anything in /logs ?
Na enig onderzoek kwam ik erachter dat dit probleem zich voordeed omdat ik sleutels van 4096 bits gebruikte. Ik heb ze veranderd naar 2048 en het begon correct te werken.
Is deze sleutelgrootte een vereiste? Is het ergens gedocumenteerd?