Project

General

Profile

Bug #5556

Wt::Auth::AuthService::setEmailVerificationEnabled simple mail verification does not work

Added by Alexandre Sanches almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
Start date:
02/20/2017
Due date:
% Done:

0%

Estimated time:

Description

Simply using wt-3.3.7-rc1/examples/feature/auth1/ as a test do the mail verification cycle (copy link in browser), in the test DB, auth_info.unverified_email is still filled, and email remains empty.

The example works as it is, BUT if I add a call to setEmailVerificationRequired(true), I can never add a working user account. The email address can never get "verified".

#1

Updated by Roel Standaert almost 5 years ago

The e-mail verification is enabled by default in the example already. I just tested it and it should at least work with the master branch.

Also, the e-mail sent will be logged. You will have to copy-paste the URL in the log, replacing =3D with =.

You can specify the server to connect to to send the e-mail with the smtp-host and smtp-port properties. See the documentation about properties in the library overview.

#2

Updated by Alexandre Sanches almost 5 years ago

Yes, my bad, I played with it before checking the code and sending the report, you are right, mail verification is required by default in the example.

And it still does not work. As I test it, I use a localhost Postfix server, and use a local address (xxx@localhost), then check the mail with mailx and copy the link to my browser. I had no need to configure any SMTP server in my situation.

But your comment showed me the source of the problem :

""\"

(...)

Please click here to confirm your registration or copy and paste the

following URL into your browser: (Note: be sure to copy the entire

URL, including any part of it which goes onto a second line.)

http://localhost:9090/?_=3D/auth/mail/fv0wBQdAfFNkEH68BnDmCV5LCECapTib

(...)

""\"

I did not notice the "3D", even in the raw text part of the mail. Which is an error, but certainly does not show to most users, who click directly on a link from the HTML-formatted version of the mail.

So the bug is real and you should fix it, but not a real problem.

Thanks for your help!

#3

Updated by Roel Standaert almost 5 years ago

  • Status changed from New to InProgress
  • Assignee set to Michiel Derhaeg
#4

Updated by Michiel Derhaeg almost 5 years ago

The "3D" you see in the logs after a "=" and when you look at the mails in the raw format are escape characters resulting from the usage of the "quoted-printable" encoding. When you look at the mail using a mail client, you should not see any of these escape characters and it should just work.

Note that newlines are escaped as well. So if you see a link that ends with a "=" on a line, and continues on the next line you should copy everything, including the next line, and remove the "=".

E.g.:

http://127.0.0.1:8000/?_=3D/auth/mail/iWDNRqhlAphRJLcMKCJnjHKE11Z=

iVbiv

becomes

http://127.0.0.1:8000/?_=/auth/mail/iWDNRqhlAphRJLcMKCJnjHKE11ZiVbiv

I hope this helps.

#5

Updated by Alexandre Sanches almost 5 years ago

Yes, but precisely... Is mime encoding in the final "pure text" part of the mail appropriate? I think not. The pure text is not supposed to generate clickable links, it is supposed to be read, copied(-pasted), precisely "as is", and nothing else.

Anyway, I consider virtually no one reads the mails in their text form, so...

And yes, you helped!

#6

Updated by Roel Standaert almost 5 years ago

  • Status changed from InProgress to Closed

The output in the logs is just the raw e-mail message as it is sent, so this will display the quoted-printable escapes.

In a mail client (text-based or not) the plain text version will be unescaped and shown properly.

Also available in: Atom PDF