[SOLVED] Email validation

I send a verification email that has a link that brings a user back and sets verified to true.

Here is the code to set verify to true:

Template.main.created = function() {
  if (Accounts._verifyEmailToken) {
    Accounts.verifyEmail(Accounts._verifyEmailToken, function(err) {
      if (err != null) {
        if (err.message == 'Verify email link expired [403]') {
          swal('This verification link has expired.')
        }
      } else {
        swal('You have been verified!')
      }
    });
  }
};

I get the the success message displayed when I first arrive, but whenever I go back to my main template after that I keep getting the error message.

I thought of creating a verify-email template and that the link somehow sends him there and then I call a timeout function that sends him back to the main but I think there must be an easier solution.

Also I want to offer to user the option to resend the verification email if it really is expired

{{ #if !Meteor.user().emails[0].verified }}

“send verification mail” (What function do I call here since the docs say i should send the mail from the server)

{{else}}

Since it seems no one knows, let me ask a different question, what are the security issues of resending the email from the client?

you can call a method to review the email of the user and if is not verified you send the email

Meteor.methods({
  'sendVerificationEmail': function () {
    var userId = this.userId;
    if (!userId)
      throw new Meteor.Error(402, 'no user login');

    var user = Meteor.users.findOne({_id: userId, 'emails.0.verified': false});
    if (user)
      Accounts.sendVerificationEmail(userId, user.emails[0].address);
  }
});
1 Like

security should be fine because all changes and validations are done on the server and the user should only see the result

Thanks for the input, I’ll do that then, wasn’t sure about the security threats since the docs say it should be sent from the server.
What about the verify token, is it a good idea to create a new template and verify the user there and then forbid access if the user is already verified, or is that too much?

put the method sendVerificationEmail on the server and the client never see him, to verify token you need to call Accounts.verifyEmail on the client, Might create a route that only verifies the user’s email and if it works you redirect to the successful verified email view

Accounts.verifyEmail is a function that call some method on the server, Meteor is responsible for security in this case

I’ve created a new template for the verify-email route but now it doesn’t verify my email nor does it throws errors and just sends me to ‘/’. Guessing verifyEmail template never gets created.

Router.route('/verify-email/:token', function () {
	
		
		this.render('verifyEmail');

})


Template.verifyEmail.created = function() {
	  if (Accounts._verifyEmailToken) {
	    Accounts.verifyEmail(Accounts._verifyEmailToken, function(err) {
	      if (err != null) {
	        if (err.message == 'Verify email link expired [403]') {
	          swal('Verification link has expired.')
	        }
	      } else {
	        swal('Address has been confirmed.')
	      }
	    });
	  }
	};

Not sure why it doesn’t work, problem with iron:router maybe?

It would appear that meteor removes everything after the # for the validation and iron:router can’t get the route.
So my solution was this:

Accounts.emailTemplates.verifyEmail.text = function(user, url) {
    var url = url.replace('#/', 'verify-email/#/')

There are some solutions online where you could remove the # but then it seems that meteor doesn’t retrieve the token and you can’t verify then.

An idea for the meteor team:

Maybe just remove the token after the #/verify-email/ so that people can use routing out of the box

this is solution validate email:

this.isValidEmail = function(value) {
var filter = /^([a-zA-Z0-9_.-])+@(([a-zA-Z0-9-])+.)+([a-zA-Z0-9]{2,4})+$/;
if(filter.test(value)) {
return true;
}
return false;
};

That’s not a good validation for a number of reasons, not least that it will not validate any TLD having more than 4 characters.

1 Like

Use regex for….validating email address

Lee

This is really not a good idea, see a post I made few days ago: Accounts-password accepts wrong mailaddresses