Proper way of implementing user authorization? - HS3 and HSTouch Designer

[dchramcow]

Client wants us to implement some sort of user authorization for his HSTouch App. The system will be used/operated by several users on the same device, and he wants each of the users to have a different password.

So something along these lines:

* Welcome screen shows a keypad for entering a password.
* After successful login, the app shows the user's full name corresponding to the password entered (on each screen's header).

Can this be achieved? what would be the proper way to implement this? maybe's there's a plugin that already does this?

Any help would be greatly appreciated, thanks!.

[dchramcow]

Bump.

[rmasonjr]

I dont think HSTouch will do this out-of-the-box. The pin code for a screen only accepts a single pin code, so you wouldnt be able to have multiple folks logging in.

That said, you might be able to heavily script a solution where a code is entered and sent back to HS to 'authenticate' which would be your own database or table, etc.
It would be quite a bit of work. I'm curious if others have a solution to this.

[Eman]

It's a bit of work in HSTouch to implement passwords. But I think you can do it if you lock the tablet in kiosk node (Android) ie to hide the menu buttons and/or change their functions.

It will involve other apps like Tasker ...etc to do the tricks.
You want the users not be able to access the tablet in any other way except HSTouch.


Eman.

[Wade]

Haven't tried anything like it, but how about this? Unfortunately several extra clicks involved.

1. Default / unsecured screen has button for each user--button opens a separate password entry screen for the user.
2. Successful password entry sets virtual device string with user's name and opens main secured screen.
3. Virtual device string is displayed at top of each screen.

Not sure whether password entry on one screen can automatically call another screen, so there might be yet another click required after password entry to get to the main secured screen.

A bit of a hack, but might work.

[Eman]

Haven't tried anything like it, but how about this? Unfortunately several extra clicks involved.

1. Default / unsecured screen has button for each user--button opens a separate password entry screen for the user.
2. Successful password entry sets virtual device string with user's name and opens main secured screen.
3. Virtual device string is displayed at top of each screen.

Not sure whether password entry on one screen can automatically call another screen, so there might be yet another click required after password entry to get to the main secured screen.

A bit of a hack, but might work.

To improve on your idea on the clicks, these can happen on elements on another screen (hidden) . The way I use such a screen is to hide the dirty work in the background and it functions as script so whatever button you click on the Home screen can be linked to process elements on that screen.
But that said, passwords were never properly implemented.


Eman.

[Wade]

To improve on your idea on the clicks, these can happen on elements on another screen (hidden) . The way I use such a screen is to hide the dirty work in the background and it functions as script so whatever button you click on the Home screen can be linked to process elements on that screen.
But that said, passwords were never properly implemented.


Eman.

Nice.