amplify-js
amplify-js copied to clipboard
aws-amplify
Auth - signInWithRedirect/federatedSignIn - add additional validationData
Is your feature request related to a problem? Please describe.
I would like to add some validationData on Auth.federatedSignIn() so that i can access this data on some Cognito triggers like Pre authentication or Post authentication.
@pechisworks why you cannot use Auth.signIn(...) instead of Auth.federatedSign(..), what is your use case?
Hi @elorzafe.
I want to Sign in with my Facebook or Google-Account. I want to pass some additional data to the Post authentication trigger, in my use case I want to pass the IAM identityId so I can take over some data from the unauthenticated IAM user. (The IAM user can do some data manipulations, and when he signs up/in, this data should be taken over to the new user)
Is it possible to sign in with a Facebook Account with Auth.signIn(...)?
@elorzafe is this possible? can we pass validationData to federatedSignIn?
For my particular use case there is a precursor step that they need to take before they can sign in using facebook, so I pass the result of that step in the validationData to ensure that the user is valid
+1 Have the same usecase as @alichherawalla. Would appreciate any update.
I'm in the same problem, it is vital for me to pass validationData for a function that runs in pre-signup and I also have federated users from Facebook and Google.
This is key to being able to validate a CAPTCHA in the Pre authentication trigger Lambda.
It's been almost two years since this ticket was open, it's really a very important feature to build production-ready sign-in/signup pages using a CAPTCHA. That will be great to get at least feedback whether you are planning to implement it or not, this will give us the opportunity to think about other solutions like AWS WAF CAPTCHA (not cost-effective for our use case) or move to another IDP.
@SimonHoiberg I am very sorry I forgot to answer this issue.
I was looking on Cognito documentation and it seems is not possible to send validationData or clientMetadata when using HostedUI.
I will reach out Cognito team about this problem
FYI: @elorzafe
Even for the clients which are not HostedUI based the validationData and clientMetadata not working for federatedSignIn/federatedSignUo
Hi @parthNJ, unfortunately we are blocked on delivering this feature since we need changes to happen first at the Cognito side. We are in communication with them about these blockers!
Hi @wookieJ - unfortunately, not yet. Can you please provide us with the use case that you want to unlock by passing the validationData?
@abdallahshaban557 We would like to pass fingerprint id to pre-signup lambda using federatedSignIn()
@abdallahshaban557 I'm following this issue as well, not a blocker for me as we are still evaluating Cognito as a solution, but in prototypes I've built this has been an issue. For my use case, I would like the to pass application context that I can rely on in cognito triggers. It basically comes down to tenant information in our use case. We use the same logic for all tenants, but we need to know the tenant identity. For federated logins we would have to infer it from other information since the client has no way to pass it to us.
Hello. We also need this for our use case.
When users sign up with a Google/Apple/Facebook account with an email associated with an existing Cognito user, I am throwing an error from a pre-signup trigger to ask the client to specify whether to link those accounts or not.
In a subsequent call to federatedLogIn, I need to be able to pass a signal to my pre-signup trigger to specify what action the user chooses to take in those cases.
This issue is a blocker for this use case, and I'll probably have to figure out a hacky workaround to implement this. Not sure what I'll do yet.
This functionality would be very useful for us.
Just wanted to drop a comment on this issue to say that while there hasn't been any progress to report on this feature request yet, we've marked it to be reviewed with the Cognito team again. If there's any updates that can be provided, we'll share them as soon as we can!
This is a must have in order to pass any extra information to the Post Authentication trigger. We really shouldn't have to justify why that is necessary.
