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:
- Database connection
- Database insert: register_user (insert options: $_POST.username & $_POST.password.passwordHash… etc)
- Security Provider
- Security Login ($_POST.username & $_POST.password)
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?
This is what I have done:
where the data is first validated to ensure a unique customer. Once the customer has registered, cycle through the Customers until the just registered customer has been found and log them in.
Would you mind sharing a screenshot @ben of your database query? I think that’s where it went wrong last time I tried this similar setup. Thanks in advance!
Thanks Ben, I had the same query, so I don’t see why I couldn’t get it working. Will try again
Also going to add the validation steps, still had to do that.
You think it’s better to cycle through the customers table to find the just registered customer instead of using the registration details right away like I did? I am sure you are right there, but can you please explain why that’s better? Thanks again!
The process cycles the one result (i.e. not all of the users/customers). This is the way that the Wappler script works.
Of course, I see. But I can’t get why the repeat is necessary then. Is it to make sure the registration has completed before trying to login the same user? Sorry if I am bothering you with this, trying to learn here… 
Not a problem.
Normally when querying a database, it is possible that there are many results.Wappler has been programmed to then cycle through those results to obtain the requested outcome.
In this case, there is only one result, but Wappler still needs to do the cycling to get the outcome.
1 Like
Or you can now use the single query instead and not use any repeat.
The single query returns one result, so you can use it directly without a repeater.
2 Likes
So instead of using the query in a repeat, it’s an option to run a single query, got it 
Last question about this topic: What’s the advantage of using a single query’s (or repeated db query’s) results over $_POST.username & $_POST.password in the security login step? That still isn’t clear to me
Looking at your case, the only reason to use the query is to check if the user is in the database.
But it would be just fine if your use the POST vars, as this simplifies the server action.
1 Like
