I've noticed that Microsoft Safe Links is triggering /cgi-bin/koha/opac-registration-verify.pl?token=X links. This means that the end user ends up seeing "Registration invalid" because the Microsoft link scanner has already verified the registration by hitting the page with a GET. We should update opac-registration-verify.pl so that it requires the user to click a button for a POST form confirming their registration. (NOTE: Since opac-registration-verify.pl performs a state change, it should be a POST anyway.)
Basically, /cgi-bin/koha/opac-registration-verify.pl?token=X will take us to a HTML form where the token is a hidden form field, and we'll have another input to indicate that we're confirming the registration.
Created attachment 159516 [details] [review] Bug 35445: Require OPAC user to confirm self-registration with button push This change requires the OPAC user to confirm self-registration with a button push when verifying registration using an emailed token. Test plan: 0. Apply the patch and koha-plack --reload kohadev 1. Set syspref PatronSelfRegistrationVerifyByEmail to "Don't require" 2. Create a patron using the self-registration on the OPAC 3. Note that no confirmation step is needed when self-registering 4. Set syspref PatronSelfRegistrationVerifyByEmail to "Require" 5. Create a patron using the self-registration on the OPAC 6. Look in message_queue to find the URL with the token to visit in the browser 7. Visit that URL 8. Note that the page says "Registration pending" and asks you to click a button labeled "Confirm" 9. Click the button labeled "Confirm" 10. Note that the self-registration is confirmed and details are shown on the page
Created attachment 159520 [details] [review] Bug 35445: Require OPAC user to confirm self-registration with button push This change requires the OPAC user to confirm self-registration with a button push when verifying registration using an emailed token. Test plan: 0. Apply the patch and koha-plack --reload kohadev 1. Set syspref PatronSelfRegistrationVerifyByEmail to "Don't require" 2. Create a patron using the self-registration on the OPAC 3. Note that no confirmation step is needed when self-registering 4. Set syspref PatronSelfRegistrationVerifyByEmail to "Require" 5. Create a patron using the self-registration on the OPAC 6. Look in message_queue to find the URL with the token to visit in the browser 7. Visit that URL 8. Note that the page says "Registration pending" and asks you to click a button labeled "Confirm" 9. Click the button labeled "Confirm" 10. Note that the self-registration is confirmed and details are shown on the page Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
All working as expected here, signing off.
(In reply to David Cook from comment #0) > I've noticed that Microsoft Safe Links is triggering > /cgi-bin/koha/opac-registration-verify.pl?token=X links. > > This means that the end user ends up seeing "Registration invalid" because > the Microsoft link scanner has already verified the registration by hitting > the page with a GET. Isn't that a security issue? It's possible to create an account for someone else and their email will be verified automatically. I don't know much of what's around self-registration, what are the bad things that can happen due to email hosts autoclicking verification links?
(In reply to Victor Grousset/tuxayo from comment #5) > (In reply to David Cook from comment #0) > > I've noticed that Microsoft Safe Links is triggering > > /cgi-bin/koha/opac-registration-verify.pl?token=X links. > > > > This means that the end user ends up seeing "Registration invalid" because > > the Microsoft link scanner has already verified the registration by hitting > > the page with a GET. > > Isn't that a security issue? It's possible to create an account for someone > else and their email will be verified automatically. I don't know much of > what's around self-registration, what are the bad things that can happen due > to email hosts autoclicking verification links? I think that you could argue it's a security issue conceptually in terms of the state change being a GET rather than a POST, but no it wouldn't work the way you're describing here. Koha sends the email with the URL to the user's mail server. That mail server rewrites the URL to point to Microsoft Safe Links or Web CISCO or whatever. Then when the user clicks the link in the email, Microsoft Safe Links or WEB CISCO or whatever visits it first, verifies that it's OK, and then redirects the user to the original link. So it still requires the user to click the link in their email. If someone self-registered as someone else, that someone else would still need to get the link and click it. It works the exact same way without the Microsoft Safe Links as well.
> That mail server rewrites the URL to point to Microsoft Safe Links or Web CISCO or whatever. Then when the user clicks the link in the email, Microsoft Safe Links or WEB CISCO or whatever visits it first, verifies that it's OK, and then redirects the user to the original link. Great, nothing to worry about then :D Since these tools don't click on the link on their own in advance.
Created attachment 161476 [details] [review] Bug 35445: Require OPAC user to confirm self-registration with button push This change requires the OPAC user to confirm self-registration with a button push when verifying registration using an emailed token. Test plan: 0. Apply the patch and koha-plack --reload kohadev 1. Set syspref PatronSelfRegistrationVerifyByEmail to "Don't require" 2. Create a patron using the self-registration on the OPAC 3. Note that no confirmation step is needed when self-registering 4. Set syspref PatronSelfRegistrationVerifyByEmail to "Require" 5. Create a patron using the self-registration on the OPAC 6. Look in message_queue to find the URL with the token to visit in the browser 7. Visit that URL 8. Note that the page says "Registration pending" and asks you to click a button labeled "Confirm" 9. Click the button labeled "Confirm" 10. Note that the self-registration is confirmed and details are shown on the page Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Pushed for 24.05! Well done everyone, thank you!
Yay! I'd love to see this one in 23.11 as well :)
Should not we adjust opac-shareshelf.pl as well?
(In reply to Jonathan Druart from comment #11) > Should not we adjust opac-shareshelf.pl as well? I'm not familiar with that one, but if it works similarly then I'd say you're right.
(In reply to Jonathan Druart from comment #11) > Should not we adjust opac-shareshelf.pl as well? Will have a look at that marvelous script :)
Pushed to 23.11.x for 23.11.03
(In reply to Marcel de Rooy from comment #13) > (In reply to Jonathan Druart from comment #11) > > Should not we adjust opac-shareshelf.pl as well? > > Will have a look at that marvelous script :) Opened a new bug 35992, but will wait first for changes from 34478.
(In reply to Marcel de Rooy from comment #15) > (In reply to Marcel de Rooy from comment #13) > > (In reply to Jonathan Druart from comment #11) > > > Should not we adjust opac-shareshelf.pl as well? > > > > Will have a look at that marvelous script :) > > Opened a new bug 35992, but will wait first for changes from 34478. Ah. Should revive that.