# Specific Client Login Information **URL:** \ **Category:** Ignition\ **Created:** [May 1, 2018, 2:24pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884 "2018-05-01T14:24:02Z")\ **Posts on this page:** 12\ **Page:** 2
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [June 24, 2021, 12:43pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/21 "2021-06-24T12:43:59Z")
I always thought runScript was only used to call functions, really cool that you can do list comprehension one-liners in them, that’s very useful. ---
**Author:** ![dkhayes117](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dkhayes117/32/68344_2.png) [@dkhayes117](https://forum.inductiveautomation.com/u/dkhayes117)\ **Post date:** [June 24, 2021, 1:25pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/22 "2021-06-24T13:25:55Z")
Keep in mind, I think @pturmel suggests only using `runScript` with functions that have short execution times. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [June 24, 2021, 2:04pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/23 "2021-06-24T14:04:08Z")
> [@bkarabinchak.psi](#): > > one-liners in them runScript has evolved from **only** being able to do one-liners to the current form that can pass arguments to functions. But only one or the other. If you wish to have inline code that also accepts arguments (without having to recompile the string), you would use my [objectScript()](https://www.automation-pros.com/simaids/doc/expression.objectscript.html) function from my [Simulation Aids](https://inductiveautomation.com/moduleshowcase/module/automation-professionals-llc-simulation-aids) module. { I created this expression function specifically to enable passing true objects into python from a binding. With other features that I think make sense. IA then added the argument passing to runScript, in a slightly different form, and credited my idea in the release notes. I pretty much always use objectScript where others use runScript. } ---
**Author:** ![LandrethEdward](https://avatars.discourse-cdn.com/v4/letter/l/7bcc69/32.png) [@LandrethEdward](https://forum.inductiveautomation.com/u/LandrethEdward)\ **Post date:** [November 12, 2024, 5:04pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/24 "2024-11-12T17:04:08Z")
What would be the correct method to change the username for the audit log? Our projects have an autologin to start. When we run our login script I can see in the audit log that it records a login action for that username, but then when we go to toggle a bit it still records it under the autologin username. We utilize the system.security.switchUser function to do this but it still doesn't update the System\>Client\>User\>Username tag so I'm not sure if I'm missing a step on how to retain that username for the tag write functions. We might be able to get away with just seeing which users were logged in when some tag writes occurred, but it would be fantastic to directly tie that user to the tag write with the audit log. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [November 12, 2024, 5:08pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/25 "2024-11-12T17:08:22Z")
I'm not having this issue. I have an auto-login as well, but all audit events are being logged under the user that performs the action. How are you performing the writes? When a user logs into mine, the System/Client/User/Username tag updates. (I know this because I show it on my header at all times). Are you sure the user is actually getting logged in properly? ---
**Author:** ![LandrethEdward](https://avatars.discourse-cdn.com/v4/letter/l/7bcc69/32.png) [@LandrethEdward](https://forum.inductiveautomation.com/u/LandrethEdward)\ **Post date:** [November 12, 2024, 5:24pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/26 "2024-11-12T17:24:14Z")
Ok, perhaps we're missing a portion of that function in our login template and looks like maybe have the hide error set on now that I'm reading it again. I will dig into this some more to see if that function actually is failing. I made a test label tied to display that tag and saw that it didn't update, but since the audit log recorded that user login I thought the function was still working. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/e/1e766e3b11f369d6831788d792ae8514147899eb.png) ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [November 12, 2024, 6:17pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/27 "2024-11-12T18:17:48Z")
You're also calling switchUser twice. You should only need one call and can check if switch is true or false to determine if it was successful. I also believe that when passing event, it will automatically close the window, so you don't need your closeParentWindow either. ---
**Author:** ![LandrethEdward](https://avatars.discourse-cdn.com/v4/letter/l/7bcc69/32.png) [@LandrethEdward](https://forum.inductiveautomation.com/u/LandrethEdward)\ **Post date:** [November 12, 2024, 6:35pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/28 "2024-11-12T18:35:35Z")
Agreed, the redundant line was me testing a direct system call to see if it had any effect so line 54 will be taken back out. That's interesting on the event window close though didn't realize that's pretty slick! The switchUser issue was that our projects are set to a default internal User Source so we can utilize a dummy autologin, but that means we aren't tied to AD for the system login. We manually call the AD user source in our script so we can set AD groups for each project so when I switched the project to one of our AD or Hybrid user sources I was able to get that switchUser function to work. Making this change though meant our normal autologin can't be used anymore since we can only set that dummy login on an internal source so we'll have to create some dummy app ID that exists in our AD. For now I just used an app ID from one of our DB connections to test. One thing I'm still having issues with now though is the logout procedure. If I use system.security.logout then it completely takes you back to the main launch screen where no user is logged in. I can do a switchUser to go back to the autologin app ID, but then I'd have to leave the password in the script which is poor practice. Any thoughts or recommendations on how to get that logout to return back to the default autologin user? ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [November 12, 2024, 6:52pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/29 "2024-11-12T18:52:04Z")
I put the password in my "logout" script to just switch back to the default user. Because this user/login isn't used for anything and in our system is read-only so they can't do anything besides change screens, it's not an issue. ---
**Author:** ![LandrethEdward](https://avatars.discourse-cdn.com/v4/letter/l/7bcc69/32.png) [@LandrethEdward](https://forum.inductiveautomation.com/u/LandrethEdward)\ **Post date:** [November 12, 2024, 7:18pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/30 "2024-11-12T19:18:58Z")
I looked at the only other old project we have running the audit log and that's what they ended up doing for the logout as well so you're right should be fine since it has no real credentials. I appreciate the feedback! That older project is somehow logging the username on its tag writes despite using that default user source and not having a switchUser function in the login so we might poke around in there to see if they've got some roundabout setup working, but we'll most likely move forward with a dummy app ID to keep things a bit more straightforward. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 12, 2024, 8:02pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/31 "2024-11-12T20:02:34Z")
> [@LandrethEdward](#): > > since we can only set that dummy login on an internal source so we'll have to create some dummy app ID that exists in our AD. Most of my clients that use AD login use it with _ **soft failover** _ to an internal user source. Then all projects, and the gateway, and the Perspective IdP, all point at the AD user source. The internal user source is where such dummy accounts go, along with contractors (like me) who don't get AD accounts. ---
**Author:** ![LandrethEdward](https://avatars.discourse-cdn.com/v4/letter/l/7bcc69/32.png) [@LandrethEdward](https://forum.inductiveautomation.com/u/LandrethEdward)\ **Post date:** [November 12, 2024, 8:41pm UTC](https://forum.inductiveautomation.com/t/specific-client-login-information/17884/32 "2024-11-12T20:41:58Z")
Oh that's a great point I forgot to look at failovers! Just set one to a soft failover and able to utilize our default internal autologin now. Thank you! [Previous page](https://forum.inductiveautomation.com/t/specific-client-login-information/17884.md?page=1)