bug for server side to generate verifier and challenge pairs

[nullne]

https://github.com/supabase-community/auth-py/blob/16e571fc19168314d82074523de6f246bdd74960/supabase_auth/_sync/gotrue_client.py#L943C9-L952C1

for example:
user A generates a url, with verifier A, user A doesn't verify immediately
then, user A generate another url, for now, previous url won't be verified by the new code_verifier

[silentworks]

I'm not understanding your explanation above. Can you use example along with step by step instructions of the issue please?

[nullne]

let me try to explain again before deploying a demo :)

in "pkce" mode, step1, a google login link is generated and not clicked. if you dive deep into the related code, a code_verifier is generated and saved to memory by default which is used to validate the code_challenge later .
step2, generate the google login link again, this time, a new code_verifier generated and cannot match the previous code_challenge, this is the problem

[silentworks]

You've just described how PKCE works. This is not a bug, it's just how the feature works.

[nullne]

it's ok for frontend lib, because browser remembers which verifier key is used, but for backend, it generate verifier key in one request, and verify it in another, in which scene backend can't remember which verifier key for which challenge.

[silentworks]

I'm looking into this to see what's the best way to handle it with current setup. Ideally we need to get the authorization code flow from Supabase, but this hasn't been implemented as yet into Supabase's auth setup.

[silentworks]

So I have a solution for this which would mean saving the sessions as cookies and then retrieving them on a per request basis. In my current setup I'm using cookies and redis, the cookie stores the session_id and redis stores the actual JWT with the session_id for the lookup. I'm going to try and create a repo with this for others to see how its implemented, I'm also almost certain it can be done with cookies only without redis, however the benefit of redis is that its a quick in memory storage and you can store larger bytes in it than a cookie.

[nullne]

So I have a solution for this which would mean saving the sessions as cookies and then retrieving them on a per request basis. In my current setup I'm using cookies and redis, the cookie stores the session_id and redis stores the actual JWT with the session_id for the lookup. I'm going to try and create a repo with this for others to see how its implemented, I'm also almost certain it can be done with cookies only without redis, however the benefit of redis is that its a quick in memory storage and you can store larger bytes in it than a cookie.

it should work. for now is there any method to pass cookies to verify code_challenge?