I found several resources on this topic. I’ve also built this for other apps. Just wondering what the Vaadin recommendation is.
I found this video on Snaplets from 11 months ago that looks cool, but there is nothing in the Vaadin documentation about Snaplets, so I’m a little confused. Are they real?
LoginForm includes a custom form area since 24.2. This could be used to provide a registration button or a link to a registration view: Login | Components | Vaadin Docs
I guess I’m confused and frustrated by the LoginForm component. Why give us a Login form at all if you’re not going to also give us a Registration form? Now I have to build my own Registration form and try to get it to look exactly like the Login form. In the end, it will be a lot easier for me to just build the entire thing myself because at least then I can easily make them look the same.
Because 99% of registration forms are different - it’s impossible to make a universal one. Even the simple login form has so many different nuances that people wanted to customize it so many times that it doesn’t really make sense for Vaadin to provide “plug and play” components IMHO. Especially now in a world where running your owns login/registration is discouraged.
That makes sense. In that case, I think it would make more sense for Vaadin to provide guidance around building the implementing these forms instead. Providing a Login a login form only does more harm then good because it obfuscates the behavior that I need to understand to build the registration form.
I’m personally not sure what kind of guidance you need / expect - technically a registration form is just a typical form for Vaadin… nothing special to be considered (except Anonymous Allowed Annotation). So any guide regarding data binding / layouting should be enough and present Data Binding | Flow | Vaadin Docs
I’m a beginner with Vaadin. From my perspective the login form magically handles user login. There’s no form submit handling or service calls. It’s much more than a simple form because of the validation and business logic to authenticate the user. Also, if it were just a simple form I would be able to reuse it for user registration.
Feels like comparing apples with oranges (not meant to be mean!)
The magic with the login form comes from spring boot - the login form replicates the behavior of spring security’s default login page by sending a post request to the spring security login mechanism. You could technically archive the same by creating a native form element with two fields, a button and a valid CSRF token.
The registration form on the other side is just “plain” / regular form / fields in a layout which you can use however you want and hook your own logic to it. (The same could be said with the login form; but nobody does that)
To compound what @knoobie said, the login form is pretty simple - it has two fields for filling in your username and password, and a button to submit (and a few other things like an error message, a title text, etc.). Note that this is not enough for every login scenario, but that’s a slightly separate discussion. This simple setup works very nicely because Spring Security - an industry-standard security framework - has a feature for form-based authentication, which you can use here, but it does require some extra attention on the login form’s side to be compatible. More specifically, Spring Security requires a HTML <form> submission with a matching action for form-based login to work, and that can be non-trivial for newbies to implement. Furthermore, plain username + password-based authentication happens to work with very many (but not all) backends, probably because of legacy reasons.
User registration, however, is a whole different kettle of fish. A bare-bones registration form that requires you to input only a username and a password is not going to be enough in a vast majority of cases. Is there a separate username and email? Date of birth? Profile picture? First name and last name? Department? Title? Phone number? Direct supervisor? Authentication id? Dietary restrictions? Emergency contact information? Are some of those mandatory and others optional? The answer to all of those questions is “it depends on the backend and the business requirements of your application”. Creating a custom Vaadin form for any permutation of different user properties is going to be a fairly simple task, but it’s probably going to be a little different every time. I don’t know if it would make sense to provide a Component for that, especially because there aren’t any requirements from e.g. Spring Security to provide compliant behavior.
As for Snaplets, they have since been renamed to AppJars, developed and maintained by Flowing Code, and you can find some information about them here: https://www.appjars.com/.
Ahhhh, ok, that’s fair, thanks for your patience. I think I was conflating registration and authentication.
Hmmm, AppJars only has a contact form. Too bad.
Control Center looks cool. I have only ever deployed to PAS like Railway so I don’t really know what Kubernetes is, but if it helps simplify hosting and authentication, that sounds great!