Develop Reference

Double verification emails sent from Cognito upon updating user email address

I am using AWS Cognito for user management in my application. The userpool is configured that the users login with a unique username and a password, and that multiple users can have the same email addess. I am using Amplify built-in components for authentification.
The problem I can't seem to resolve, are double verification mesages upon updating user email. When an an email is chaged CustomMessage_UpdateUserAttribute is triggered, and when user wants to verify the changed email CustomMessage_VerifyUserAttribute is triggered. I have a custom lambda function that listens for these triggers among others and sends corresponding emails based on the action user is trying to perform: login, verify email, reset password etc.
So if a user modifies his email address, CustomMessage_UpdateUserAttribute is triggered and the user recieves an email with the following (default) message "Please verify your account and enter the following verification code to reset your password: xxxxxx". However, when this user loggs in, amplify recognises that the user is in the "verifyContact" state, and displays the screen you can see below.
The user has two options:
to skip the verification, or
to select the only attribute that awaits verification and click on "verify" button.
Clicking on the "verify" button triggers CustomMessage_VerifyUserAttribute and sends yet another email to the user. The user is redirected to the following screen.
The second screen shows where user is supposed to input newly sent code (from the second email). So the user has absolutely no need for the first email (and code) that is sent automatically when the email is updated. I have tried to find a way to avoid sending the email, but have not found a good solution. Congito won't let you override the message in lambda without sending the confirmation code in it, which is completely unnecessary since there is no place where user can input it. I don't want to disable email verification, or set email_verified to true upon updating.
Do you have any suggestions what I could do?

If anybody is facing the same problem, a workaround is to update email_verified field twice. When updating the email, set email_verified to true. This will prevent Cognito from sending and email on CustomMessage_UpdateUserAttribute. Then in a separate user attribute update request update only email_verified field to false. This will set the user to "verifyContact" state and request email verification on login.

Is it possible to create a one way "request form" in my app?

Ive created the UI design for a "request form" in which the user enters their request for a specific song. Id like the user's request to be sent to my email, but the user wouldn't have to use their own email, theyd just have to enter the details and click the button whcih would then sen m the request. Is this possible? If it is how can i apply this. if not then is there another way? Thank You

You cannot send message without mail address, but you can create a mail by yourself, hardcode it into your app, and use as sender address. Also you can pass all data about user that you need (if you collect it), if you want to recognize one, in the message

Disable link after click sent through JavaMail

I am using java mail and activation to send email to the user. When user clicks forget password, a mail is to be triggered to user email with link for resetting the password.
I dont want user to use same link again, so when he clicks the link from email...the link should get disabled..
I am not sure how to do it...
String body = "<a href='resetpage.jsp'>Reset Password</a>";
Message message = new MimeMessage(session);
message.setFrom(new InternetAddress(username));
message.setRecipients(Message.RecipientType.TO,
InternetAddress.parse(email));
message.setSubject("Password Reset");
MimeBodyPart mbp = new MimeBodyPart();
mbp.setText(body, "UTF-8", "html");
Multipart multipart = new MimeMultipart();
multipart.addBodyPart(mbp);
message.setContent(multipart);
Transport.send(message);
From this code, i am getting the link in email..but now after user click the link in email..the link should get disabled..or i want to make sure..when user clicks the same link again it should not work..

If I understand you correctly you would like to enable the user to click a link that will achieve some functionality and thereafter invalidate the link to ensure that it cannot be reused for performing another change.
What I would suggest is:
Generate a token of some sort UUID.randomUUID().toString() would work nicely.
Store the token in the database with something to indicate who it was for and what function it would allow (Joe Soap, Password reset)
Send a URL to the user including ?token=[token_string_here]
When the page loads check the token exists and display the function you wish to make available.
When the code makes a change to the user / account, check that the token exists again before performing the action and then delete the token from the database

Have you thought of using a random token for this?
This token could be included in the link (reset.jsp?token=RANDOM)
Whenever a user is directed to the reset page, it could read the given token and mark it as used.
When a used token is used again, you could redirect the user to another page (e.g. the login page or an error page).
(I am aware that this may not be a complete answer to your question, but I am unable to add a comment to your question.)

QuickFIX/J how to disable auto logon response

I'd like to perform some operations after receiving LOGON message and then decide if LOGON failed or not (for example check username and password) but...
Immediately after receiving LOGON message QuickFIX/J resends:
8=FIX.4.4|9=74|35=A|34=13|49=FIXserver|52=20110831-09:27:41.847|56=localhost|98=0|108=10|10=131|
8=FIX.4.4|9=71|35=2|34=14|49=FIXserver|52=20110831-09:27:41.855|56=localhost|7=1|16=0|10=213|
How to disable this functionality?
Second question. If LOGON failed, should I resend LOGOUT message or something else?

Call you required methods which do your logon checkins and other checks in onLogon. You can disable sending messages in toAdmin. Entry points for messages is fromAdmin and sending point is toAdmin.
No need to send logout message as logon didn't happen. You logout out of a session only if you have logged in.

How to manage multiple accounts login and logout in different browser pages?

I have a website built on App Engine(Java) and need user use Google Account to login.
The situation is that:
User Adam has multiple accounts.
User Adam login with account Adam1 and get his Adam1 data in browser page A.
He clicked logout link, but opened it in another tab page B(the same browser of course)
He login with another account Adam2 in browser page B get his Adam2 data shown.
He then returned to browser page A and made some changes to his data and then send to server, at this time my app would recognize the current user is Adam2 , and the changes would be taken on Adam2, it does not match the status with its current page A, our user may be confused.
I thought maybe I can attach a userID parameter while making change request to the server and server side will compare the current user id with this userID parameter to make the change request processed or return a refresh command to make the out-of-date page be refreshed to the current account's if the ids are not same.
What is the best practice to handle this situation?

Put a hidden field on your forms that is a combined hash of the session ID and the user ID. When your server processes the request, double check that the combined hash sent along with the request matches what you expect. If either the user or the session is wrong, the hash won't match, and you can report an error appropriately.

Presumably the user would be identified by a Session ID that is send as Cookie information. Adam on site A will have a different Session ID than Adam on site B because of the differing login. Also presumably the form page will be protected such that a user needs to be logged in in order to access it.
When Adam logs out on page B, the old session is destroyed on the server and the login becomes invalid. When Adam submits the form from page A, the browser doesn't know this has happened and will submit the form together with the old Session ID. The server will (should) reject this submit since the session has already expired.
Hence, in a properly coded Session/User management system, this becomes a non-issue. The critical point is to renew/invalidate the Session ID upon logout.