Cannot add Friendica account anymore.

[kr428]

59.15 from fdroid seems to have issues adding Friendica 2022.12 accounts. Chose Mastodon, entered my instance name (loma.ml) and ended up with "entity could not be processed". Known problem?

[yvolk]

@kr428 Please check if this problem is caused by an upgrade. Previous versions may be downloaded e.g. from history of changes here: #456

[yvolk]

I just checked if adding an account at mastodon.social works with current code: yes, it does.
So this looks like a problem that may need friendica developers for a fix.

[kr428]

@yvolk I downgraded to 59.10, re-added the account - which worked - and upgraded to 59.15 afterwards - which left it working, on the same Friendica instance. So it feels like this is somehow related to changes in between 59.10 and 59.15 for the initial signup / auth procedere? Any info I can provide to debug this?

[yvolk]

@kr428 The problem is probably related to this improvement of compatibility with OAuth 2.0 specification. That fix may affect services that followed Mastodon's implementation instead. See #561
Please note that even after this change AndStatus still can successfully add an account at Mastodon instance (I tested this yesterday at mastodon.social ).
Please read that thread with our notes on testing.

In order for me look at this, I need to have a test account at a Friendica server having the latest development version. Could you provide such an account for me?

[kr428]

Trying to ping @annando here. I think squeet.me runs latest development version of Friendica; maybe however (looking at #561) this might require changes in Friendica as well?

[annando]

Squeet.me is on dev, but not the current one.

[yvolk]

@kr428

this might require changes in Friendica as well?

Maybe this will be Friendica-side change only...

@annando

[yvolk]

Hi @annando , I checked Squeet.me and I don't see any registration link there.
Anyway, I tried to log into squeet.me, and got similar response from a server as @kr428 there during opening authorization web page:

1. AndStatus opens the web page:

https://squeet.me/oauth/authorize?response_type=code&client_id=62149b5c194dff7b20644d36599624386475b9efb668bf5bb08fed0c3235ca63&redirect_uri=http%3A%2F%2Foauth-redirect.andstatus.org&scope=read%20write%20follow&state=state_65_1673634926129

and instead of an HTML response gets this:

{
    "error": "Unprocessable Entity"
}

Probably this is caused by addition of "client_id" to the Access Token Request as required by OAuth 2.0 spec, see my comment #561 (comment)

Friendica code should be adapted to handle this normally as this conforms to the spec.

[annando]

Yeah, since squeet.me now has around 5,000 users, at some point in time I closed the registration. BTW: I just saw that you still has got a test account on my machine that I use for developing: pirati.ca.

[yvolk]

BTW: I just saw that you still has got a test account on my machine that I use for developing: pirati.ca.

Yes, I tried pirati.ca yesterday also. Didn't remember that it is also yours :-)
In my old AndStatus setup Pirati.ca is still "GnuSocial" type of social network... tried now and got that even your old profile there currently is mapped to some other person... (consequence of using numbers as local users' IDs...)

...Oops, and after your profile update in AndStatus your profile was changed to some "Kai ..." :-(
At least my replies to you are still the same. I turned syncing off to avoid old messages corruption. Will login as to Mastodon account after this "Unprocessable Entity" fix.

[annando]

I try to work on it this weekend. So possibly you can even test it before I created the PR.

[annando]

I just saw that on creating the app the redirect_uris is transmitted as array. Currently we only support a string here.

I made a fix for this. But still it doesn't work. AndStatus is posting to oauth/token with only the client_id but not with client_secret like the other apps are doing. And I also saw that the app had been registered with only read scope, but the call to oauth/token then includes read write follow.

According to https://docs.joinmastodon.org/methods/oauth/#token the client_secret has to be set and the `scope' can only contain elements that had been part of the app registration.

[yvolk]

@annando Thank you for information.
Regarding Client registration please see #561 (comment)
Currently AndStatus makes up to two attempts to register:

1. OAuth 2.0 - compliant (see https://www.rfc-editor.org/rfc/rfc7591#section-3.1 ) - please see that "redirect_uris" IS an array according to the spec.
   "scope" is here, according to OAuth 2.0
2. If the registration fails, AndStatus makes the second attempt, this time - with a hack for Mastodon.
   "redirect_uris" is a string, "scopes" - Mastodon's Auth...

See the metadata for these attempts:

andstatus/app/src/main/kotlin/org/andstatus/app/net/http/HttpConnectionOAuth2.kt

Line 96 in 1789140

// Client Metadata https://www.rfc-editor.org/rfc/rfc7591#section-2

[yvolk]

@annando I would suggest for Friendica to support standard OAuth 2.0 also, not only Mastodon's custom variant
OR fail at the first attempt (as Mastodon does)

[annando]

What about the missing client_secret upon requesting the token?

[yvolk]

@annando
I see that Access Token Request (POST) to https://pirati.ca/oauth/token does have "client_id" body parameter yet the sever responds with 401 Unauthorized.

Oh, I see that you mentioned "client_secret". Please see below.

[yvolk]

Regarding failure due to absence of client_secret.
As was noted here: #561 (comment)

that's weird, it looks like Mastodon token endpoints require both client_id and client_secret: https://docs.joinmastodon.org/methods/oauth/#token

I think we better not add client_secret here because it's not even an optional parameter, see https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.3

BTW mastodon.social server does work without client_secret here.

[annando]

Concerning the client_secret I found this: https://www.oauth.com/oauth2-servers/access-tokens/authorization-code-request/

If the client was issued a client secret, then the server must authenticate the client. One way to authenticate the client is to accept another parameter in this request, client_secret. Alternately the authorization server can use HTTP Basic Auth.

and: https://www.oauth.com/oauth2-servers/access-tokens/client-credentials/

The client needs to authenticate themselves for this request. Typically the service will allow either additional request parameters client_id and client_secret, or accept the client ID and secret in the HTTP Basic auth header.

So for me it seems as if the client_secret has to be provided all the time.

[yvolk]

@annando Aha-ha :-) I've started to remember that we had similar discussions some time ago... And yes, I see that you and me discussed exactly the same thing two years ago :-)
Please look here: #537

Please see this comment from the thread I was reffering to: #530 (comment)

[annando]

AFAIK that discussion had been about where to fetch these values, see the code here:
https://github.com/friendica/friendica/blob/develop/src/Module/OAuth/Token.php#L56-L72

[yvolk]

I see where I think the bug is. From your code:

if (empty($request['client_id']) && substr($authorization, 0, 6) == 'Basic ') {

Since recently AndStatus started to post client_id in the request body of the "Access Token Request", which is allowed according to the specification. But I see that your code, seeing this "client_id" in the body, doesn't even try to look in the header, where both client_id and client_secret, I think, are still present (I didn't change that).

[annando]

The PR is merged. It should work now again.

[yvolk]

I tested that I can add an account at pirati.ca (as a Mastodon Social Network). And can post...
Thank you, @annando !