Checking current user password in perspective

For default security provider, is there any way to check current user password in perspective session?
I need this because for sending some commands, system should check to see if the one who send the command is actually the one whose is already logged in.
In vision there for this purpose but there is not such option in perspective default security provider.

There was a force auth added to the login:

This will force the user to re enter his credentials. I just don’t know how to wait for that in your script. Interested to know

This cause login logout loop to send a command.
Not acceptable for client

User information is available in the session properties


Or are you looking for something like

# When forceAuth is True, the user will always be required to type in their credentials, even if they're already logged in. 

system.perspective.login(forceAuth = True)

I need similar behavior like in vision.
Just simple function and I get user password and pass to it and it check and them true and false.
The system.persective.login function is really slow and it re download all session resource each time which is not ok here.
I just need to confirm the command issue by the operator and not someone else.

There’s nothing like this, and probably won’t be, due to how identity providers work. If you’re concerned about users other than an authorized user working from a Perspective session, configure automatic logout/idle timeouts appropriately, or train users to lock/log out their sessions appropriately. You can’t perform a direct authentication check with an identity provider, other than the full session redirect & login.

So is there any way I can get all user password that already save in default identity provider?
If I can access this table I can do this manually.

Not it any supported way. All passwords in Ignition’s internal DB are salted and hashed, as well.

For a different idea, that you can implement yourself - what if you maintain your own table of user PINs/etc in your own DB, then require the user to positively verify before doing anything? That’s something you could absolutely do.

1 Like

Sure. Good idea and easy to implement.