Password field in WHERE condition?

There is no password field in Rollbase.

To clarify:



If I query for the column password, I get the error:



>Error SQL query contains illegal keyword password (line #3) in formula:

var result = rbv_api.selectQuery ("SELECT id,name FROM employee WHERE password='test'", 1);



If I quote the password column name with backticks (the MySQL convention), I get the error:



>Error Column password cannot be resolved.

var result = rbv_api.selectQuery ("SELECT id,name FROM employee WHERE `password`='test'", 1);

Ah, OK. Thanks, Pavel.



I was thinking of the field that is created when you mark an object as Portal Visitor. You get a Login Name field, and a field named Password.



In the fields list, it has a data type of Password, and an integration name 'password'.



Is there a way for me to match against that stored portal visitor password?

"password" is reserved keyword. You cannot use it in SELECT statement.

Hi,



Why would you need to check against the password field?

When you create portal pages and set them to require login to be accessible you are already assuming that a person has successfully validated his password before access of said page, in this regard you can already use the current user or visitor tokens like user name and id to perform your triggers, rather than trying to get the password from the db.



Hope this helps,

Piscoso, Martin

Rollbase

Hi Martin,



I'd really rather not retrieve the password from the database. Instead, I'd like to send the entered password to Rollbase and let Rollbase tell me whether it matches or not. What I want to do is allow performing an authenticated action from the portal front page. I want to allow people to walk up to a computer where no one is logged in, type their username and password, and click a button. In this scenario, the person has definitely not validated his password before access of the page.



I also don't want their clicking the button to result in logging them in. I want the system to authenticate them, perform the action, and then land back at the same non-logged in front page. This way there can be 3 or 4 employees standing around, and they each enter their own username and password to punch in. There's no chance of one of them accidentally leaving the system logged in to their account. After they've punched in, the system is immediately fresh and ready for someone else to enter their own usernam

Hi Nathan,



I'm assuming this is for your custom portal login that we discussed previously. In this scenario you can still use the standard portal login of Rollbase here.



After they login and click the punch-in button use a window.open call so that they are redirected to the punch-in page, on the onload of this said page, preload the punch-in data and programatically submit the form via document.theForm.submit() js call, additionally, you can add window.resizeTo(1,1) so that it scrunches to a small window while the submission is happening.



After the submit, redirect to a View page (create a new one) and on the onload of this page, add an onload alert, maybe containing alert('You have successfully punched-in.'); then after the alert call, place a self.close() call to automatically close the window after the OK button on the alert is clicked.



This way you won't need any triggers, still use the functionality and validation of accounts from the standard rollbase portal capabilities and retain your scen

I forgot to specify that the punch in button will be the login and you will still use a landing page, on that landing page this will be the page where you will call the window.open to the new punch in page, after the call, redirect the landing page back to the login page using window.location.href = 'loginurl'. This will happen at the same time as the punch in record is being saved.

Hi Martin,



Thanks for that. I'm going to keep this approach in mind.



I've actually already set it up a different way. I'm going to make a post about when I have a minute.



Thanks,

Nathan

Duplicate of the password field to a regular text field for querying?

Hi Martin - Something a little different, actually!

Marking as Answered