Ok, so here’s the solution: @owen, please use the off-the-shelf Discourse User API Key mechanism. Use it to let the user approve access of your application to their edgeryders.eu user account. Which means, the URL to forward them to for approving the application’s access is NOT https://communities.edgeryders.eu/... but:
https://edgeryders.eu/user-api-key/new
This is the default mechanism provided by Discourse for authenticating external applications. We should not try to roll our own alternative for this, because we’d have to maintain that for years, and we already know that all authentication related customizations easily break during Discourse updates. We spent three hours looking for other alternatives like JWT based authentication, but there is no ready-made solution for Discourse anywhere. So we’ll go with what Discourse provides out of the box.
As a result, you’ll have three cases:
-
If the user does not yet have an edgeryders.eu account, your application uses our custom
multisite_account.jsonAPI endpoint as before. -
If the user as an edgeryders.eu account and is logged into it, your application forwards the user to
https://edgeryders.eu/user-api-key/newfor approving access to their edgeryders.eu account. That takes only a single click, and then the user is forwarded back to your application. -
If the user as an edgeryders.eu account but is not logged into it, your application also forwards the user to
https://edgeryders.eu/user-api-key/new. From there, the user will be forwarded to communities.edgeryders.eu for login, then back to approve the application, then back to your application. This is obviously annoying, but will happen only in 5% of cases as people typically stay logged in.
You can (and should) save the resulting User-Api-Key value in offline storage into the user’s browser. That way, authenticating the application has only to be done the first time the user uses it.