Best Practices for Login Verification using 2 number value fields before Go To Form page?

Wappler General
1

In past PHP projects 2 years ago I validated a User login before they could be passed on to fill out a 12 field form & submit to the database table for records. I used Wappler documented procedures of 2019-20.

Now in 4.4.5 I am back in a PHP/MySQL application that must run on a client"s server in a folder in the path of his WordPress site. I know the server & my previous apps worked fine.

In 2022 I want to upgrade my methods and use the API Work flows & Security components.

The user login asks for a 7 digit number assigned to the user by our client as the “username” and the “password” is a 5 digit number they will know for their own business region.

The login query will search a preloaded table with the “username” unique numeric value.
AND the “password” Post value for this User’s business. “Select (5 fields) FROM ‘validatelogin’ where username = {{$_Post.Username}} AND password= {{$_Post.Password}}”. Either the unique client record is found or it fails.
In 2019 I modified the User Identity default Wappler login form to just use 2 values as described above.

But in looking at multiple ways to skin this cat now from the different tutorials created over the past couple of years I"m trying to cut to the chase and use the best method in Wappler today.

I don’t want to copy what worked in 2019 for me.
I wasn’t a power user then and am not a power user now with Wappler.

Recently had set up an URL passing variables to be used in a query that was not using a Security provider yet
I want to see the query working with the post values that are not generated until the Submit is used. I’m dithering between using the Submit default form function or to use a javascript click method to pass along variables at the button itself.

@ben has a tutorial with mucho steps https://www.youtube.com/watch?v=3Xrg4EUMRIQ

Before I commit to slavishly following Ben, as I usually have done, I"m doublechecking: looking for any other logical step one, two, etc with Wappler tools reliance.
And, of course, until the user credentials have been verified I don"t want to SET Session values with the first username & password submitted. Only AFTER User verification should I set the Session ID.

I identify at least 3 different methods in this kind of project to take that have me wondering if you experienced Wapplerites have their own semi-sleek Best Practices workflow using Wappler for this – 2 form application – customary login, verify, warning on no success, retry & finally pass through and set the Session after verification.

Or do you recommend that I stick with our main man @ben ?

2

Obviously the credentials are not stored in plain text within the DB? You could verify the hashes match for these credentials, using exists in database for validation… If I understand what you are asking for above correctly that is?

First you’ll hash the inputs to match the DB contents, then check they match, then carry on with the Action, or show a Toast if there is an error with validation.

3

I’m not actually sure what you are trying to do @NewMedia…? So looking back at my reply it may not be of use to you, but may be of use to others, so will leave it in place.

4

Hi, Dave

Yes, this is the Tutorial I had been following while also looking at Ben's.

Probably some confusion is happening when people read my post because I used the term "validation". I was actually intending to refer to VERIFICATION -- verifying the Identity of the User.

As in "Is this User a valid User, verified as someone with permissions to log in".

On this post I headlined what I meant -- " . . Login Verification . ." then inconsistently slipped into "validation" which as it is used in the world of web DOM terms leads the reader astray from my careless meaning.

Naturally forum readers would wonder why I was talking about the difficulty of input type validation such as making an input of numeric or alphanumeric characters conform to such patterns as an email@gmail.com "valid input", etc.

What I was actually referring to was trying to make use of a Session value on login to pass to the form page and other pages as needed. I didn't want to set the login page submit values of "username" and "password" or Identity ID until AFTER the verify Query had produced a Success result.

SUCCESS! Yes, these login values match one unique record of User credentials we have stored in the "verify_user" table.

Now set those values in the Session manager as what we use for other queries in the user"s logged in form submission or filtering of data.

Which is essentially the process outlined in the Check if a Database Record already exists. only my action expects to find one record that matches the login values and If so only then Sets Value of these credentials into the Session Manager and Go To formpage.php.

I was trying to decide if I needed a combined approach between Ben"s steps and the Wappler Documentation. I'll figure it out today. Perhaps winding up going through the same steps as 2 years ago.

Thank you, Dave.

5

I'm trying to learn about the Session Manager and I came across this post from the past --

I'm moving through it to see how things like this are resolved in Wappler.

6

So, DAVE -- I see you were quite involved with this discussion.

The last issue you talk about COOKIES is what has concerned me before -- Does the User"s browser on laptops, desktops, smartphones 99.7% of the time SUPPORT Cookies.

Now after 2021 how is the reliance on Browser cookies working out for your log ins?
I don't want my client to report ANY login issues because some user got a warning from a Cookie Check. These users wouldn't accurately describe their problem, anyway.

DaveWappler Pro Company License

Jan '19

We love Cookies. Set/Remove/Expire all so simple. Used correctly they can help with all sorts of scenarios and can save a huge amount of unnecessary effort. It’s worth insuring your Users have Cookies enabled by using the Browser component to display an Alert and hide any content if the User has Cookies disabled, prompting them to enable Cookies, and preventing unnecessary reports of errors by Users with Cookies disabled. We usually apply a ‘CookieCheck’ Div enclosing the primary content area. Then this way if the Users Cookie permissions are set to disabled no content is displayed aside from the aforementioned Alert. :wink:

Glad you have it sorted and am sure your Client will be happy with the result!

7

I'll start here. Within the Action used for the entry point/login you can have a repeat that looks up the User, and then you can set server side sessions containing any verification criteria you need, then double validate, treble validate, and more if you really wish to, matching the input to any number of fields contained within your User table. You can then send a response from the server side for success or failure, all server side. I'd suggest whatever you use for validating the Users access meets a minimum length and complexity, and is stored hashed, ie a password. You can check the values provided match those stored within the database.

Use the Set Session in Server Connect to do this. Then you could use these Sessions within your queries as Conditions.

Set sessions server side, as mentioned above.

Just take a look at any major site, Social Media platforms, and you'll see cookies are still relevant in many ways. Always make sure they are Secure, and don't store anything too sensitive in them, and if you do hash it or at least implement some sort of data obfuscation.

We do not rely in any way upon cookies, we use them to aid in storing User preferences, be it colour scheme, language, etc. The thread and responses you direct to above were a suggestion to aid in rectifying an issue Brian was having, but is also a good example of how to implement cookies if necessary. Cookies are still a widely used part of most applications so nothing much has changed. Dependent upon the type of data our applications provide dictates its security measures accordingly. Some are session and token, some are RSA Secure ID based, others are bespoke, and some use Security Provider combined with other factors.

Hope that clears some things up a little for you @NewMedia?

1 Like
8

I think that you are overthinking the issue, keeping in mind that I kept my tutorial as simple as possible. There are more complicated ways to verify the user.

Rumour has it that @Teodor will come with a complete solution in the very near future. If the issue is not time restricted, it will be worth the wait.

1 Like