• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Question Global Event Parameters for Event Handlers

pleskuser67553

Basic Pleskian
Server operating system version
AlmaLinux 8.10
Plesk version and microupdate number
18.0.63 Update #4
Hello,

I have read this Event Parameters Passed by Event Handlers but I'd like to be able to pass the IP address that triggered the Event. Are there any global parameters that are always passed by Event Handlers? If so, what are they or how would I discover them?

For additional context, it's for a simple script I have to notify when a user is logged in but I want to know the IP address too please Resolved - Event Manager - Plesk user logged in not firing The IP address is revealed in Tools & Settings > Log Browser > Action Log, so I would hope it can be accessed by the Event Handler too.
 
I don't think the login IP address isn't available as a environment variable for this particular event. (Would be nice if it was). If you want to be sure you can dump all available environment variables into a file with a script like this:
Bash:
#!/usr/bin/env bash

env > /tmp/params # Or any other location

Unfortunately the "Plesk user logged in" event probably isn't of much use for your particular use case. The data shown in the Action Log is stored in the PSA database log_actions table. Sadly it's difficult to fetch any additional data based on the event paramater (contact name). What you could consider doing however, is to query the database table and just return the most resent logged cp_user_login action.

I am not sure if that actually does gets you the data you need. Because the event might get triggered before the login data gets stored to the action log (so you might end up with data from an previous login action). But this might be worth testing. It's the only thing I can think off that comes close to what you're trying to accomplish.

Hope this helps.
 
Back
Top