Prior to this, the success callback provided three things:
an object that holds the session function for creating a new token and redirecting back with the token in the hash,
The input that holds the provider, the tokenset and the oauth client
the raw request
This PR adds the redirect_uri and response_type to the first object alongside the session function. It also tries to get these values from the query params as an alternative to the getCookie helper.
The reason I'd like this to be added is because the session function is doing too many things for my usecase. In a Next.js application, I have an API route that acts as my final callback to the front end. This API route is server side and does not expose the hash on the Request object. The flow is like this:
SST Auth lambda redirects to www.frontend.com/callback#access_token=abcd1234 ----> Next API Route picks up the request and loses the access_token because the hash is never sent to the server. I believe that is just part of the HTML spec.
If we can also expose the redirect_uri and response_type here, I can do the redirect in my app without using the session function. I'd be able to append the access_token as a query parameter which does persist between across to the server.
The alternative to this PR is changing how the session function works and instead of appending the access token and state to the hash, we append it as a query parameter.
Prior to this, the success callback provided three things:
sessionfunction for creating a new token and redirecting back with the token in the hash,inputthat holds the provider, the tokenset and the oauth clientThis PR adds the
redirect_uriandresponse_typeto the first object alongside the session function. It also tries to get these values from the query params as an alternative to thegetCookiehelper.The reason I'd like this to be added is because the
sessionfunction is doing too many things for my usecase. In a Next.js application, I have an API route that acts as my final callback to the front end. This API route is server side and does not expose thehashon the Request object. The flow is like this:SST Auth lambda redirects to www.frontend.com/callback#access_token=abcd1234 ----> Next API Route picks up the request and loses the access_token because the hash is never sent to the server. I believe that is just part of the HTML spec.
If we can also expose the
redirect_uriandresponse_typehere, I can do the redirect in my app without using thesessionfunction. I'd be able to append theaccess_tokenas a query parameter which does persist between across to the server.The alternative to this PR is changing how the
sessionfunction works and instead of appending the access token and state to the hash, we append it as a query parameter.