2

I'm trying to solve the next problem. User uses web app to sign up via Cognito. During sign up he must point out some data (like website, name etc). After successful sign up user profile should be automatically created in DynamoDB with 'sub' attribute used as id. Ordinary db access is done via API Gateway + Lambda. The problem is surprisingly Cognito doesn't have "post sign-up" lambda trigger which looks the most natural for such purpose. "pre sign-up" trigger is dangerous since sign up can fail, "post confirmation" trigger is too late because user data was lost already. One step possible approach is storing all data as attributes in Cognito and copy them to db on any sign in if user profile not present. But it's an additional undesired db call on any login. And the approach is not flexible since if someday we would like to change data attributes count or format, there is nothing we can do with already created user pool. Two step approach is when on sign up only login-password pair is used and all data is asked when user signes in for the first time using the app (like "Please fill in profile details before starting to use the app") It looks ok, but I would like to have one step approach. Is it possible?

Arsenii Fomin
  • 3,120
  • 3
  • 22
  • 42

2 Answers2

2

You could use any Cognito attribute (either custom or built-in such as profile) to store signup information temporarily until the user is confirmed (PostConfirmation_ConfirmSignUp gets triggered), at which profile will be written to DynamoDB and cleared from Cognito.

Khalid T.
  • 10,039
  • 5
  • 45
  • 53
  • So you suggest to convert all data to some string, store it as attribute, then inside trigger lambda create user profile in db by parsing this string and manually delete the attribute from cognito, right? Are there any limitations on attribute string length/format? – Arsenii Fomin Apr 18 '18 at 10:54
  • @ArseniiFomin Right. The limit is 2048 bytes ([source](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)) – Khalid T. Apr 18 '18 at 10:59
  • Looks like working approach. :) I'll try it out, thank you. – Arsenii Fomin Apr 18 '18 at 11:14
  • The approach works. The only thing is making "profile" attribute required or not. As stated, required attributes are required for registration that makes sense. But it appeared that they are also required to be present in cognito forever. So you can't have required profile for registration and then delete it. Thus you can either having required profile and set it to empty string or something small after creating profile in db (as I understand the core idea behind profile attr deletion is not to increase token size for every auth) or make profile not be required attr. – Arsenii Fomin Apr 19 '18 at 05:23
  • You're right. You shouldn't set it as required since it's just a one-time temp placeholder to help you store the basic signup info in DynamoDB. Validation should be done somewhere else (client-side or back-end, if any) – Khalid T. Apr 19 '18 at 06:13
0

In my web application I don't rely on Cognito to add anything to DynamoDB.

I do it like this:

  • User signs up using Cognito, confirms email etc
  • User logs in using Cognito and gets redirected to my webapp landing page
  • My webapp landing page loads the user's profile from DynamoDB (using the Cognito sub returned from Cognito). If no profile was found, or the user details have changed, I add/update the details from the id_token to DynamoDB.

The way you are doing it sounds fine, but wanted to mention this alternative method.

You can find my landing page code here https://stackoverflow.com/a/47796072/4985580

F_SO_K
  • 13,640
  • 5
  • 54
  • 83
  • Looks like you've described "two-step" approach as I've called it. Or user attributes are stored somewhere I wasn't expected like token. – Arsenii Fomin Apr 18 '18 at 11:14
  • What are the reasons you don't rely on Cognito? I mean in reality there is only trigger from Cognito having sub and other attributes in common format, real database write is processed in custom controlled lambda code. – Arsenii Fomin Apr 18 '18 at 11:16
  • Yes, I agree this is 'two-step' so maybe isn't what you want. Cognito user attributes are returned in the id_token. – F_SO_K Apr 18 '18 at 11:20
  • Its not that I don't trust Cognito. I don't use Lambdas and have all my AWS service code in my webapp, so its just the pattern I am using. – F_SO_K Apr 18 '18 at 11:21