OMG! It works! I can now easily log in as any user!
I built a simple form that only admins can see that when submitted using a server connect changes the security1Id value and reloads the app with the new user!
Man, I love Wappler! 
Thanks Jon, Ken and Teodor for making me look like a freakin' genius in front of my boss yet again!
Glad you got it working. The session_start() is something you need to remember if you use any non-Wappler PHP scripts otherwise the session variables won't be available.
And make sure any script which sets the security id session var is nice and secure as it will obviously enable the user to log in as anyone. 
All done 100% with the Wappler UI ..... 
Congrats Brad!
Just make sure that you ALSO check on the server side, that the user making this request is in fact, an admin. Hiding it in the UI is good for the user experience, securing on the back end is what keeps it secure.
Yep, did that ... but the staff we have using the dashboards are barely able to input data correctly let alone try and hack the system.
Only takes one click on a link to a kitten charity...
I have a starter question...
If you create and maintain the website and already have an Admin account, why not just create also a simple User account for yourself so you can do any test you want whenever you want?
And simple login from the account you need to visit the site (as a User or as Admin)
Sometimes the goal is not to test, but rather solve problems specific to that user, which may include changing settings, billing details...
Because more times than not it is my staff member seeing wrong data or not seeing missing data that they are suppose to see. It helps to be able to see and test what the actual user is experiencing with live data.
I do have a dummy user account I use during development.
Has anyone done this on NodeJS..? How was it done?
I started a while back with extending the security provider for NodeJS, an impersonate action is already added in the auth module but is still WIP and no UI exists.
The impersonate does nothing more than setting the session variable to a specified identity. So you can do the same with a simple Set Session step, the name is securityId (simple the security provider name + 'Id') and set value to the userId.
Thanks for the confirmation Patrick...good to know this is acceptable since it is part of the security model.
For NodeJS+Aargon, we had to get creative and modify the core Wappler file to get this working.
We also use DB as the session store.
If we only set the user ID session on server side, would it still work?
I’ve just done this in Nodejs and Argon and it was a doddle, didn't have to go near the core code. What part did you have to change..?
We set the session server side and it worked perfectly.
You mean just the id in server side session?
And do you use DB as session storage?
I don’t like this from a security perspective.
Impersonation Tokens:
Instead of directly changing the session, we can use a temporary, signed token for impersonation. This token can be verified and used to get the impersonated user’s details without messing with the original session. It keeps things secure, making it clear who the original and impersonated users are.
Or: Session Isolation:
We can create a separate session for the impersonated user. This way, we avoid any session conflicts and keep the original session intact.
Hello!
I don't exactly get this, sorry if I'm missunderstanding something here, but if your security provider is simplelogin then $_SESSION['simpleloginId'] will always be the identity of that.
So how it's insecure if you manually change it on a server side?
If there's no session at all, what's the issue on setting one as the security provider does with $_SESSION['simpleloginId']
Sorry for asking, just trying to understand it !
Yes, we use DB session storage. We send a user ID via form from behind a ROOT ADMIN section in our site. It uses a SC API that sets the session according to what user id is sent to it, API is protected by our security restrict for the root admin. here it is:
This bypasses the user login so that isn't recorded in the user timeline table, instead, we add the log in event to the ADMIN timeline so we can see which admin initiated it f we ever need to audit.
So, while setting the session server-side might seem straightforward, using these methods helps us enhance security and maintain clarity. It’s about adding an extra layer of protection and ensuring our approach is robust.
My Node.js method currently uses simple hash swapping. All within a server action you can: store the current user hash password in memory (here, assuming hashed with argon), update it with a hash of a known password, login using the creds of the known hash, then update the user hash back to the original. The time the user’s password is invalid for them is usually less than a millisecond and no need for any special back doors at the app connect level. Am I missing anything with this implementation?