FORUM CTRLX AUTOMATION
ctrlX World Partner Apps for ctrlX AUTOMATION
10-10-2023 02:48 PM
Hi,
Our customer requests a logbook for different user login. Users of different role has different rights/views he can access in the HMI. Hence, user log is required. Any idea how I can create the log?
The visualisation is built on WebIQ Version 2.13, on CtrlX Core V1.20
Solved! Go to Solution.
10-11-2023 08:18 AM
I'm not sure if I understand your question correct. What I understand is that you want to create a log file which contains the following data:
1. Is that correct?
Right now there is no build in log feature, but it is on the feature list of WebIQ. I don't know a schedule.
When you need it right now, the only way I see is to implement it by yourself with java scripts.
10-11-2023 08:26 AM
This is currently not possible with WebIQ, but audit functionality is currently in development.
A workaround with JavaScript can only be used when ensuring that all users only access the HMI on locked-down systems, i.e. with kiosk-mode browsers. Otherwise the user could simply use the browser's development tools (F12) to disable the JavaScript code that logs the login or even manipulate the user name logged.
10-11-2023 09:46 AM
Hi,
yes that is exactly what I am trying to achieve
10-11-2023 09:54 AM
Hi. Yes, the webbrowser to access the visu will be done in kiosk mode. Do you have an example code of the javascript for this purpose?
10-11-2023 11:04 AM
The only thing you can do with WebIQ here is have a LocalScript that s executed when the HMI is loaded (i.e. after the user has logged in).
This LocalScript then reads the user info (shmi.visuals.session.UserManager.getCurrentUser()) and sends it via a HTTP(S) request to another URL that then records it. That "other URL" has to be implemented by you then as it simply receives some data via a URL and shall write it to a log file or a database.
10-11-2023 03:53 PM
Alternatively to use a webServer saving the log info I see the following alternatives:
10-12-2023 10:17 AM
10-12-2023 10:59 AM
What this does is the following:
1. It sets an item to the user name that just logged in
2. It then triggers the alarm
3. Whenever someone logs in on any other HMI a new login will be logged as an alarm in addition
This has the following potential issues:
a) If two people login on two different browsers at almost the same time one login user name might not be logged as the context item already has the value of the second user and the first user's login is not logged - instead two logins of the second user will be logged (it's all asynchronous and network latency needs to be considered)
b) If you have the HMI open on multiple browser windows each login will be logged multiple times, once by each open HMI and implicitly with a different timestamp (10 HMIs open = 10 user login logs for a single login) - this can be fixed by simply removing this part of the code as it is not required
This can work if you only have a single system (i.e. browser window).
When using an external tool where you only send the information to this will not happen, because there you send the user name directly and even multiple logins at the same time will be handled (if you tool has been programmed correctly of course).
However, when the user logs in to the server itself using the API this will not be logged in both cases.