Hello, I’ve finished my user log in, reset pass, but I’m having a problem with the registration page.
What I’m trying to do is to allow people to create a user in my page only if they have a unique code and a verification number that I give them, this is because my page it’s only for my costumers and each of them have a unique code.
So… I’ve tried creating a query in the server action file to lookup the values… WHERE Code = Input_Code and Verification = Input_verification.
Then using a conditional, if the verification and the code values are correct, it allows the person to create a user.
I’m trying to do this for a while know but I can’t seem to make it work.
Hi @salvuccicarlos,
from what I understand you could achieve the above by adding a user level and verifying it through security provider. Consider this
Create a user-level named ‘superuser’ or anything you want.
Create a column in your db named user level and give to these users a level of 3 for example
So when the user level for this user is 3 then give them the ability to add a new user.
Just in case you are doing something similar to me (for which @t11 usually perfectly valid approach isn’ suitable).
I also have users from customers who sign in to the same platform as other customers but should only be able to perform actions for their users/records. Even more complex was that I can have single users that have access to several customer areas so need to be able to switch between them.
in the DB I have tables for: user, customer, activations
When creating the user they are given a corresponding record (foreign key) in activations with a further foreign key link to the customer record. There can be multiple activation records per user, linking to each of the customer sections that they have access to.
When the user logs in I set a ‘last_customer_uid’ (link to customer table) field in the users table to remember which customer they were last logged in to (although you then have to make sure it copes with a NULL value or assign the new customer uid when creating a new one)
Each customer has a unique ‘private key’ that is only ever seen server-side (I usually use a concatenation of fields from the customer record and hash to create a code - include a timestamp, if you keep them private, to make it less guessable)
Each user has a unique ‘private key’ that also is only ever seen server-side (I usually use a concatenation of fields from the user’s record and hash to create a code)
A public key is then created as a hash of the two private key values within a database view and is retrieved via Server Connect db query.
The public key can then be sent with the relevant user identity and customer uid (obtained through login) to verify server-side. It is unique per user and per organisation so (I think) would be incredibly difficult to manipulate.
Permissions can be set in the activations record for the user/customer combination
It is a bit of a trial to get set up, but once working I find it pretty effective.
Ok, my English is not very good so if there is any misunderstanding, that might be the cause.
Being more detailed about how my system should work, I’m going to list my tables and fields.
TABLES:
Costumers
ID
Verification number
Name
Users
ID
email
password
Customer ID
The steps should be the following ones:
A costumer complete the registration form and the server checks if the email doesn’t exist (validation).
The server makes a query to the DB to check if (Conditional) the ID and the verification number retrieves one costumer. If the server retrieves one costumer, it enables the registration and creates a new user with the Costumer ID.
If the query doesn’t bring any costumer (else condition), the page shows an error.
Note: Response 100 should show the name of the costumer (is just to test the steps). Response 400 shows the error (the page is only showing this one).
I believe the problem is with the query. I created an alert to show how many records counts from the query and shows me 0. I don’t understand why, because I’m using the correct ID and verification numbers to test the query.
First the validation…You don’t necessarily need to do a query action for this. After your database connection step, add a Validate Data action. Here’s an an example from my app that makes sure the email address doesn’t already exist in our users table:
You also can remove the Response actions. Currently you are telling the server to do a query, the loop through all the query results and send a response back to the client, for each of those results, and then send another response. So, it really doesn’t serve much of a purpose.
If you want to see results coming back from the query, just click output in the query properties on that action.
You also mention debugging. You can click the debugging box on the query properties, which will output a bunch of debug info, but it will no longer send the standard output of results. Use this only to see the sql, parameters, etc. that are in use.
Also, make sure the debug is turn on in the settings:
@salvuccicarlos
Server connect runs the steps in the order they are placed. Currently your repeat first runs the response 100 and then the response 400 - so you will always see response 400, as it is the last step.
You don’t need a repeat here. Just use the condition step after the query, and use the query {{query2}} as an expression.
If the query returns results, the steps in “Then” will run. If the query returns no results, the steps under “Else” will run.
For returning test data better use a SetValue step, instead of set Response
If you are trying to validate the data in your query, you can click output on the query and see all the columns you selected in your browser developer console.
If you really want to see the value from a single column like nombre, add a repeat step after your query action, and set the expression to {{query2}}. Inside that you can use a set value, with output ticked, and give it any name you’d like (it does not have to correspond to the column name.) Looks like this:
You have the debug option turned on for the query action – you only use that to see what the sql parameters and statement look like. Turn that off, and you will see the results output.
Well, if you have any issue with your server returning errors or similar, enabling the debug mode helps us to debug the problem by reading the debug info.
You don’t need this enabled for your production work.
