Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flaws in Spring Security UI Plugin - Reference Documentation #123

Open
monetschemist opened this issue Jan 14, 2021 · 1 comment
Open

Flaws in Spring Security UI Plugin - Reference Documentation #123

monetschemist opened this issue Jan 14, 2021 · 1 comment

Comments

@monetschemist
Copy link

monetschemist commented Jan 14, 2021

There are two pieces of misplaced text in the Reference Documentation that should be rearranged.

Section 5.2 ends with:

The post-registration destination url is configurable in grails-app/conf/application.groovy using the postRegisterUrl attribute:

If you don’t specify a value then the grails.plugin.springsecurity.successHandler.defaultTargetUrl value will be used, which is '/' by default.

In addition, each new user will be granted ROLE_USER after finalizing the registration. If you want to change the default role, add more, or grant no roles at all (for example if you want an admin to approve new users and explicitly enable new users) then you can customize that with the defaultRoleNames attribute (which is a List of Strings):

grails.plugin.springsecurity.ui.register.postRegisterUrl = '/welcome'

That "grails.plugin..." doesn't belong where it is; instead it should follow the first paragraph above "The post-registration destination url..."

Section 6.1 ends with:

The emailBody property should be a GString and will have the User domain class instance in scope in the user variable, and the generated url to click to finalize the signup in the url variable.

grails.plugin.springsecurity.ui.register.defaultRoleNames = [] // no roles

or

grails.plugin.springsecurity.ui.register.defaultRoleNames = ['ROLE_CUSTOMER']

The three lines just above, explaining the settings for defaultRoleNames, belong at the end of section 5.2 above.

Besides that, I believe there is something wrong with the whole explanation of using email as part of the registration workflow.

There is this comment at the end of section 6.2:

RegisterController and its GSPs assume that your User domain class has an email field. Be sure to either rework the workflow (using the s2ui-override script) if you don’t need an email confirmation step or add an email field.

Taken together with this comment in Section 5.1:

By default e-mail validation for user creation is turned on. If you wish to turn it off see the 'E-Mail Validation Parameter' section below. If this is turned off then no e-mail is sent to the user and they are automatically redirected to the link that would have been sent in the e-mail.

it seems to me that there should be some advice right up front in Section 5 or 5.1 that says something along the lines of "if you want the e-mail validation for user creation and forgot-password to work as might be expected, you must update the User domain class to include the String field email".

Finally, and not sure that the Reference Documentation is the place for this, but it would be really helpful to have somewhere an explanation of customizing the RegisterController and RegisterCommand to add new fields and incorporate new kinds of checking on them. I've muddled my way through to a solution that seems to work, which I would be delighted to document (perhaps as a Grails Guide instead of a brief tutorial section in this document) if that would be of interest.

@monetschemist
Copy link
Author

For what it's worth, I have finally managed to successfully replace the default RegisterCommand with one of my own, in this case to introduce a further check on the email field, and that is documented here:

https://stackoverflow.com/questions/65694046/grails-3-3-9-spring-security-ui-3-1-2-generate-error-for-duplicate-email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant