After user registration, no email verification happens

[Olaf Mandel]

When enabling the EmailVerificationModule module, users that registered via the RegistrationModule do not receive an Email, and see neither their Full name nor their Email-address in the General tab of their Preferences page. Only when entering the Email-address a second time, is the verification Email sent and their account is locked down until verifying the address.

Steps to reproduce

Attached are two scripts I use to create the error on a Fedora 17 machine. I can produce the error both with the distribution-provided executables as well as with a fresh Trac 0.12.3 and AccountManager 0.11. For the distribution-provided binaries, use testit.sh as is. For the unmodified code, first run gettrac.sh (generating the directory trac-for-bug-report) and edit testit.sh to use the generated programs before runing that script.

• Run the testit.sh script, to creates a directory project-for-bug-report under which an empty Trac project is created and then a stand-alone server on port 8000 is started
• Visit that page in a browser (e.g. ​http://127.0.0.1:8000/project-for-bug-report) and then click on Register in the opper right corner
• Fill out all fields (full name is optional) and click on create account
• Observe that no Email is being sent
• Log in to the system and visit the General tab on the Preferences page
• Observe that both the full name field and the email field are empty

The Email-address behaves as it it was not set, but no other user can register with the same Email-address anymore. At any later point, do the following:

• Under the General tab on the Preferences page, re-enter the Email-address and save
• Observe the arrival of a verification Email and that the account is locked down until the Email-address has been verified

Analysis

When looking at the database after registering but before re-entering the data in the Preferences page, I notice the following:

sqlite3 -header project-for-bug-report/db/trac.db "SELECT * FROM session; SELECT * FROM session_attribute;" gives:

sid|authenticated|last_visit
olaf|0|0
sid|authenticated|name|value
olaf|1|name|My Name
olaf|1|email|me@mydomain

After successfully reregistering, this becomes:

sid|authenticated|last_visit
olaf|0|0
olaf|1|1343845157
sid|authenticated|name|value
olaf|1|email_verification_sent_to|me@mydomain
olaf|1|name|My Name
olaf|1|email|me@mydomain

Actually, just calling sqlite3 -header project-for-bug-report/db/trac.db "UPDATE OR IGNORE session SET authenticated=1;" seems to do the trick.

Possibly related bugs

It is possible, that these bugs are related to this, but I cannot tell from the error description: #9052, #9090.

[Olaf Mandel]

Downloads a fresh trac environment

[Olaf Mandel]

Sets up a demo Trac project and runs a stand-alone server

[Steffen Hoffmann]

Your report is next to perfect, still I'm tempted to close it as duplicate, since you're essentially repeating old observation.

Obviously you've missed the important notes in #9079, #9252, #9843 and #9090 about a hotfix that is available in trunk development branch since changeset [11826].

Would you be so kind as to test against latest AccountManager code and report you findings, please? I'm especially interested in your feedback, because I don't have a PostgreSQL test setup here. Thanks for taking care.

[Steffen Hoffmann]

Hm, I don't see a hint on PostgreSQL anymore. Anyway, there rest still stands as is. Looking forward to hearing from you.

[Olaf Mandel]

Replying to hasienda: -Snipp-

Would you be so kind as to test against latest AccountManager code and report you findings, please? [...]

I thought I had tested against trunk already, but it turns out my gettrac.sh was strongly buggy: I still used the distribution supplied code even when I thought I was using the "clean" code. With the attached corrected script, the problem is gone.

Thank you for the quick reply and sorry about the duplicate report.

[Olaf Mandel]

Corrected version of gettrac.sh