Self registration fails if user is not logged in as an admin

[acsr]

Failing Functionality

• Self registration is not working in Volto for anonymous users.
• If you have a general proper setup a required permission for anonymous users seems to be missing.

Steps to reproduce the behavior:

1. fresh blank Plone 6.1 Volto deployment created using Cookieplone
2. activate the following options in Volto Controlpanel -> Security:
   • Enable self-registration
   • Use email address as login name
   • Login user after password reset (already activated, left as is)
3. a working Mailhost is configured in Volto Controlpanel -> Site -> E-Mail
4. Mailhost tested in /ClassicUI/@@mail-controlpanel
5. Frontend domain configured in Volto Controlpanel -> Site -> Volto-Settings
   • Hint: If your domainname contains three dots: use the ClassicUI Controlpanel -> Volto Settings (it will not show up anymore in Volto, but it works!)
6. tested the password reset procedure with an existing user
7. new Incognito Browser window
8. append /register to your url
9. in the register dialog page enter a user name and a valid e-mail address
10. send the form
11. error banner shows up: "Error Unsuccessful HTTP response" with your input preserved

Workaround

1. open a new tab in the Incognito Browser session and visit your URL
2. login with an existing standard user
3. try to send the original form from the first tab with the old error message displayed again -> same error
4. retry: logout from the second tab and login again as an admin
5. try to send the original form from the first tab with the old error message displayed again -> Success!
   • Account Registration Completed The registration process has been successful. Please check your e-mail inbox for information on how activate your account.
   • If you append a target url like /register?return_url=/registration-landing-page the target is not visited. You stay on the page from where the registration process was instantiated.
6. got an registration confirmation e-mail with a link containing the proper four dot frontend url
   • you can complete your password setup and later login.

Expected behavior

• Registration should work for anonymous users.
• Receive a confirmation mail to set your password (if configured to do so)
• You should be redirected on success to the appended redirect URL

Software

• macOS Sequoia 15.3.1 on Apple Silicon
• Browser Chrome
• Volto Version 18.8.2
• Plone Version 6.1.0
• Plone REST API Version 9.11.0
• deployment created using Cookieplone 0.8.3 template 91f7d2b

[acsr]

@fredvd Addendum: With activated SSO the /register form does not appear anymore. Instead you get the regular Login | Select a Login Provider overlay with e.g. Log in with Github

[fredvd]

Yes I already suspected that. Registration forms nirmally don’t make sense with sso, so volto-authomatic is very likely patching / overriding that form.

I’m not for sso against all costs though. If we can’t get kr working together and it has serious drawbacks for a confernce swtup, we’ll reconsider. I’ll ask @ericof for his opinion as well.

[erral]

Yes I already suspected that. Registration forms nirmally don’t make sense with sso, so volto-authomatic is very likely patching / overriding that form.

I’m not for sso against all costs though. If we can’t get kr working together and it has serious drawbacks for a confernce swtup, we’ll reconsider. I’ll ask @ericof for his opinion as well.

I object to that.

It depends on project-to-project.

There are people who just don't want to use SSO for whatever reason, and keep registering on the website. Or clients that request both options.

So we can't just disable the register form when SSO is enabled.

volto-authomatic creates another URL for the login (/fallback_login) to keep that working

[acsr]

@erral I was introduced to /fallback_login yesterday. But there is still an issue with the selfregistration. Manually registering people is not an option for events.

[acsr]

@MrTango can you confirm here that your solution we worked on today for tagung.plone.de was to fix plone.restapi?
see: plone/tagung.plone.de@1ca29ce

[MrTango]

yes, plone/plone.restapi#1889
This is one way to fix it, it could also be fixed on the frontend side, by not sending sendPasswordReset parameter.
I don't get the usecase for it anyway.