Little edge-case bug with headless google app login?

[mdaizovi]

I might have found a little bug with headless google login, or not? You tell me.

A few days ago I was trying to implement login with google provider for the first time with a headless app (react native). I kept getting a generic error (I think “invalid token” but I forgot) and after lots of debugging I found that the reason is because I had more than one google app in my settings (SOCIALACCOUNT_PROVIDERS['google']['APPS']) and when get_provider is called from SocialAccount here, the client_id is not provided. The client_id is accessible in the request, but get_provider doesn't check for it. I found this could be solved in either of 2 ways:

• Removing the other google apps so there is only 1. It turns out the others were unnecessary anyway, I only had them bc I wasn’t sure if I needed the iOS and android clients there or not (turns out you don’t, only web)
• Adding a custom adapter and grabbing client_id from the request, if client_id is not provided.

Is this a bug? Should I prepare a PR to check the request for client_id if it's not provided?

[pennersr]

I am not following -- as documented here, when you post the token you are required to send the client_id with it:

https://docs.allauth.org/en/latest/headless/openapi-specification/#tag/Authentication:-Providers/paths/~1_allauth~1%7Bclient%7D~1v1~1auth~1provider~1token/post

That client_id is used to look up the proper app.

[mdaizovi]

Yes exactly. In this call here, get_provider is called without providing the client_id in the kwargs. so it is None in the default adapter, UNLESS I write a custom adapter

    def get_provider(self, request, provider, client_id=None):
        if not client_id:
            request_body = json.loads(request.body)
            token = request_body.get("token")
            if token:
                client_id = token.get("client_id")

        return super().get_provider(
            request=request, provider=provider, client_id=client_id
        )

OR if I don't do this, it also works if I remove my other 2 apps in the settings. Which as I said, ended up being unnecessary anyway so I think this is an edge case, i don't know if any apps have a legitimate reason to have more than one app of the same provider.

If you're still not following, I suggest you reproduce the issue by adding a second app of the same provider, for example google, and try to create an account. I predict you will always get an invalid token response, even if you provide the same legitimate credentials for the same google APP twice.

[mdaizovi]

Okay. I think it's edge case and non urgent, just thought I'd bring it up. Would it be helpful if if took a look at the existing test cases and checked if i could create one, when i have some spare time?

[pennersr]

I too have a RN project up and running, which has two Google SocialApp instances. For me, this setup is working just fine. It's not an edge case, in such setups you often deal with a mobile and social app variant. So most definitely, anything you can do to shed some more light on this is helpful.

[mdaizovi]

okay, so I reproduced each of the conditions I was describing and got the terminal output. The only thing I changed from terminal output is I redacted my google client id. I've included the code in a feature branch which I'll be linking to as I describe each condition. I made my repo public so you can see the code, which is fine now bc is just a stater project, but it won't stay public forever.
I have a custom adapter, but unless otherwise indicated in each Condition below, the only code change from DefaultSocialAccountAdapter is print statements.
I used the exact same request every single time:

{"provider":"google", "process":"login", "token":{"client_id":"<MY GOOGLE CLIENT ID>", "id_token": <THE ID TOKEN I GRABBED FORM MY RN PROJECT>}}

Conditions:

1. I have three google clients in my settings. Response is 500 Commit code here, terminal output here. You can see in the print statement that get_provider is called twice and in the first call client_id is present. The second time, it is None
2. I have three google clients in my settings. Response is 500, because I changed get_provider to raise if client_id is None so you cold see full sequence via the traceback. Commit code here, terminal output here.
3. I removed the two unnecessary google clients from settings so there is only one google client. I removed the Exception I added in previous condition, so client_id can be None, which it is but that's no problem with only 1 google app. This call is successful, 200 status code. commit, output. After this call I deleted my user so next trial has same conditions.
4. There are once again three google clients in settings, but this time the adapter grabs client_id from request in get_provider, if client_id is None. This call is successful, 200 status code. code, output.

I was wrong about one thing in my initial post a week ago, the only time I get 400 response is when my id_token has actually expired. In these conditions I got 500 twice and 200 twice.
So as I said in first message above, I found that if you have 3 clients of same provider in settings, the app will not work properly because the second time get_provider is called from SocialAccount here, the client_id is not provided. The client_id is accessible in the request, but get_provider doesn't check for it. I found this could be solved in either of 2 ways:

• CONDITION 3: Removing the other google apps so there is only 1.
• CONDITION 4: Adding a custom adapter and grabbing client_id from the request, if client_id is not provided.

Is this a bug? Irrelevant edge case? Or am I misusing allauth in some way?

[pennersr]

Is this a bug? Irrelevant edge case? Or am I misusing allauth in some way?

Thanks for the detailed information, that really helps. It looks like a bug, and I think I have it caught in a test case now. You can follow along here:

https://codeberg.org/allauth/django-allauth/issues/4262

[pennersr]

Can you give this PR a try? https://codeberg.org/allauth/django-allauth/pulls/4263