Closed talyh closed 2 years ago
I noticed there's been some movement in the issue in terms of assignments, but no additional info. Are you able to provide an update on this?
Thanks,
Hello @talyh, I am working on reproducing this issue and will get back to you with an update before Friday.
Cheers,
Eddy
Hello @talyh, Thank you for the detailed explanation. I'm trying to confirm if this is related to another open issue here. Can you try adding trailingSlash: true,
in the next.config.js
file and see if that has any effect on the issue described here?
Thanks!
@Khairo-kh - I just looked at our next.config.js
and it already has trailingSlash: true
.
@Khairo-kh @evcodes - Wondering if you have an update on this? Anything I can help with?
Hey @talyh - Sorry for the delay! unfortunately, I have not had any success reproducing this issue. I can successfully get the custom state data (and sign-in) both in the local dev environment and with a production build deployed to Vercel. Please let me know if you would like to see the setup I have, I can add you to the test repo I used to try and reproduce this.
On a side note, you can enable Amplify logging without using a third-party package. Simply add window.LOG_LEVEL = 'DEBUG';
in your code and you will see the logs in the browser console. See this for reference.
Hi @Khairo-kh Thanks for looking into the setup. As far as I can tell, there's nothing in our configuration (neither in Vercel nor in AWS) that'd lead to prod behave differently (though there are so many moving pieces that it's hard to say for sure). I did open a ticket for our AWS support and they confirm that both the staging and prod pools are identical in their configuration (sure, different app ids, different domains, etc, but the same setup). So I'm not sure where else to look in terms of configuration differences.
Maybe a different approach is: Can you help me understand what are the conditions that'd trigger these errors we saw on the production environment?
(Also, thanks for pointing me to the logger! I missed that and indeed it'd have been really helpful during that investigation)
Hi @talyh just wanted to check in with you and ask if you are still experiencing this issue and in need of assistance?
@chrisbonifacio - Yes, this is still an issue
https://github.com/aws-amplify/amplify-js/issues/8594#issuecomment-893975315 provides the latest information requested by the AWS team, but I haven't seen any further action on it
Just leaving this here for anyone else that might be trying to pass custom state as their users are signing in with federatedSignIn. I wasn't able to find many clues on stackoverflow, in issues or elsewhere.
Auth.federatedSignIn({
provider: CognitoHostedUIIdentityProvider.Facebook,
customState: "hello"});
'hello' will be encoded in the url as sign in redirects are taking place, such as:
http://localhost:4539/?code=f9327f9c-93d4-42a1-920f-b02700fa1e2d&state=SNnqsphf8sDUyTTCyokuIfeI9NRnzh7f-4c49535341#_=_
specifically in the 'state' parameter, after the dash ("-"), corresponding to "4c49535341#=" in the example above
import { urlSafeDecode } from "@aws-amplify/core";
urlSafeDecode(router.query.state.split("-")[1]))
Hi 👋 Closing this due to inactivity and being unable to reproduce the issue.
For clarification, you can read Social Sign In documentation on how to read customState
after the user is signed in.
You should listen for Hub
instead of parsing the URL.
This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.
Looking for a help forum? We recommend joining the Amplify Community Discord server amplify-help
forum.
Before opening, please confirm:
JavaScript Framework
React
Amplify APIs
Authentication
Amplify Categories
auth
Environment information
Describe the bug
TLDR: Google Sign In with
customState
works on local dev/hosted staging, but not on production.CONTEXT
We run a NextJS react app, deployed within Vercel. This app has an Amplify config file that maps to either a Prod or Staging Cognito user pool, based on an env variable that determines whether it's running prod or staging. In both cases, that setup looks like this, with the `XXXX` just representing the appropriate values for each Cognito pool. ``` javascript Auth: { region: 'us-east-1', userPoolId: 'us-east-XXXX', userPoolWebClientId: 'XXXX', oauth: { domain: 'xxxx', scope: ['email', 'openid', 'profile'], redirectSignIn: 'XXXX/validation/', redirectSignOut: 'XXXX/validation/', clientId: 'XXXX', responseType: 'code', }, } ``` On their setup, these Cognito pools are the same (same policies, same attributes, etc), only with different domains under `Domain Names`. They also have equivalent apps setup, with OAuth configured the same on both sides. Both the Prod and Staging Cognito pools have `Identity Provider` configuration pointing to the same Google Cloud Project, which is configured to accept request from both sources. Both are associated to the same organization and region within AWS. --- On app initialization, we start listening for auth events. That looks like: ```javascript useEffect(() => { // We want to initialize amplify before setting auth state to avoid race condition between them initializeAmplify(); dispatch(setAmplifyInitialize(true)); Hub.listen('auth', ({ payload: { event, data } }) => { switch (event) { // // .... sign in & sign out events here // case 'customOAuthState': dispatch(loggedInRedirect({ customState: data })); break; default: break; } }); // eslint-disable-next-line react-hooks/exhaustive-deps }, []); In this context, `dispatch` is dispatching to our redux store, so the rest of the app can react to it. ``` --- Before triggering the sign in, we generate some relevant state, attached it to an encoded string, save it locally. We then send the encoded string as `customState`. That looks like ```javascript await Auth.federatedSignIn({ provider: 'Google', customState: encodedState, }); ``` The `/validation` page (set in the `redirectSignIn`) has logic to compare that locally saved state with what's in redux. If they match, we redirect the user to the page they were at when sign in was initialized.HOW THE ISSUE MANIFESTS
The flow above works well on local dev and hosted staging environments. We see the `customState` event firing and the corresponding state being set in redux. In production, however, we don't see the event firing and no redux data. There are no console or network errors and the user token is present. With the exception of the token, everything else seems to work. We initially suspected a race condition happening in prod that didn't happen on staging, but after some experiments, discarded this theory. We then used [`patch-package`](https://www.npmjs.com/package/patch-package) to add some logging to `@amplify/auth`. With this logging, we were able to see ![image](https://user-images.githubusercontent.com/23743595/125881479-15cc8973-2999-4f81-adc2-91f4be1e9bd5.png) --> It's worth calling out that this silent errorring consumed many hours of debugging, so a minor feature request inside this larger bug report would be for the error to be more explicit to avoid wild goose chases. The error above wasn't sufficient to indicate to us why this would yield different behaviours across different environments. The querystring we receive in return has `code` and `state` in both cases. The value of `state` in the QS seems to be encoded by Amplify, so hard to say what it actually contains in each case, but it is present at all times.Expected behavior
customOAuthState
or failing itReproduction steps
The bug description has all the details I can provide, but I can't offer repro steps as I only have our own Cognito pools to test with.
Code Snippet
Log output
aws-exports.js
No response
Manual configuration
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
customState
event/data in production.idToken.payload.nonce
, which we don't see in staging. To the best of my understanding, this is not related to any configuration of ours, but rather something Cognito is deciding to do.We since updated to
This didn't help matters