Adding a repeat is an extra unneeded step actually.
and about your clients getting impressed so easy. i wish my client was like this 
and another point you still need to verify the email (like amazon do) before login the user. or you are opening the gate of spam and fake accounts to your application.
Thanks Niko, great tutorial, I would have done it almost exactly the same as you, although i also would have left out the repeat, not that i think it matters at all to be honest.
I agree, this is like any programming where even if you manually coded it you might do it different to the next person, both ways work, there will always be someone with a better way, or a different way, as long as it serves your purposes and works, then great.
I have also done systems like this before although they are normally only for internal administration where the users are a little more trusted, where I have used this for a more open market, the only thing i did a little different is push the data through Akismet, once Akismet returned all ok then i marked the user as trusted, I then sent an authentication email and gave the user 1 week to authenticate their email address, once authenticated I marked the account as confirmed.
I have to admit i still had many junk accounts created and to this day I still get at least one a week that try their luck. I do not think there is any real way around this though, just do what we can and know people will still do strange things regardless.
great tutorial… this could be inserted in the Wappler docs
Welle they actually get impressed by the overall result. Actually they are impressed by the fact that everything asked is developed. Yes email verification is a good to have, but in this project autologin was more important than possible spam accounts.
Hi, new user here, so I apologise for digging up an old thread, but since it’s related I didn’t want to create a new one.
I currently have separate register and login server actions (which work fine independantly), but much like @Freddy_Blockchain, I’m attempting to auto-login the user upon sign-up/registration.
I’ve added a Server Connect element to the page, and set the Action to my login Server Action (No Auto Load selected). So in the success callback of the of the registration form (Success Dynamic Event), I added an action to load the Server Connect element, but obviously this fails in the browser as my Security Login step of the Login Server Action needs the username and password set (I’m guessing this is the issue).
How can I resolve this? Thanks in advance.
Hi Niall,
Please check the following guide:
Hi @Teodor, yes, I’ve seen this guide, but from what I can tell (I’m not familiar with Dreamweaver whatsoever), the registration and login steps are all bundled as one server action here.
I have them as separate server actions as I previously described, and so, when I call the Login Server Action from the Success Dynamic Event of the Register form, I’m not sure how to pass the required values to the Login Server Action (it currently gets them from $_POST.email and $_POST.password.sha512(…blah…).
Perhaps my issue might be that I’m not familiar with Dreamweaver at all, and so I’m not 100% sure how all of these steps translate to Wappler.
I hope that clarifies things a little?
Well if you need to do this kind of auto login, then it needs to be in the same server action 
Ah, thanks for clarifying. I figured that having the login in its own file would help reduce possible duplication and improve re-usability.
You can’t send POST variables from a dynamic event, they are form variables, you would have to send them as GET parameters.
You could create the login server connection (no auto load) then run it from a ServerConnection.load() event within the success event with the parameters set within that load parameters
Can be done that way but much less secure, personally i wouldn’t do it that way.
Indeed it’s not secure. All of the sensitive data should be handled on the serverside i.e. register + login steps to be in one server action.
Thanks @Hyperbytes - I guess that’s what I was trying, but didn’t see a way of adding the params to the ServerConnection.load() function without editing the code.
Adding the parameters is easy but you risk exposing the login details to the world, it is not a secure way of doing things.
Thanks for clarifying - I was also thinking of perhaps storing the email and hashed password as a session variable (object) and place a conditional on the Login action eg.
if (session.user) {
Security Login // configured to use the values set in the session
} else {
Security Login // configured to use the values from $_POST
}
destroySessionVariable() // no longer needed
This would keep it all server side but I couldn’t find a way of making this work. Just brainstorming here.
The options there appear when you create GET vars in your server action.
I guess that means you have not yet declared the $_GET parameters in the server action yet?
The parameters in the properties mirror the $_GET parameters in the linked server action
Ah, thanks again for clarifying @Teodor and @Hyperbytes. Yeah, I certainly don’t want that as they’d be passed and exposed via the url.
Many thanks.
I have been trying to make this work for a while and finally came up with these server action steps to register and auto login users:
Passwords are hashed with Argon2id and all happens in one server action file, so it must be secure, right? Advantage of this method is that the repeat and get_registered_user steps can be left out, besides that this setup works for me and I couldn’t get the one from the tutorial working 
Any comments?
