The screenshot on the right shows an overview of the configuration for event handling with the Log message event action:

• The Triggering event here is 'Client logged in' (see Login (Events))

• The Validating rule uses a With rule to determine whether a guest user who has never logged in is now logging in:

  • The Entity property resolver defines the User of session as a temporary reference object for the rules evaluated below.

  • An AND junction (see Junction) of two rules follows below:

    • The Check type checks whether the reference object is a guest user.

    • The following Entity property rule compares the Object property 'Number of logins' (loginCount) with the static integer 0 to ensure that actions are only executed if the guest user has never logged in.

• As the only Action on passed rule, a Log message event action is executed, the parameterization of which is explained below.

• The static text WELCOME is entered directly as the Name for the Log message event action.

• The Message with three placeholders for parameters (see below) is also defined statically via direct input:

  Guest user #{0} from {1} as {2}

  ►NOTE◄ As the log files mainly contain English content, Localization is not used here (see Value from localization).

• The Level is defined by selecting INFO in the combobox provided as the default. Technically, a Static enumeration value resolver is used here, which refers to the static enumeration 'Log level' (LogLevel).

• Three value configurations for the Parameter ({0},{1},...) follow:

  • {0}: The first value configuration reads the Object property id from the return value of the User of session resolver.

  • {1}: The second value configuration reads the 'Name' (address.Name1) field from the address of the company account returned by the Company of session resolver.

  • {2}: The third value configuration reads the 'role name' (roleName) field from the return value of the Role of session resolver.

►NOTE◄ For Guest users, unique selections are mandatory for the 'company' (companyId) and 'role' (roleId) fields. However, as the internal field names suggest, the guest user account only references 'Company' and 'Role' without including their detailed data. As the relevant Parameters in the Message are supplied with plain text, access via a Company of session and a Role of session is more efficient here.

• The 'Client logged in' event serves as the triggering event (see Login (Events)).

• The Validating rule refers to the User of session as a reference object for an AND Junction via the Entity property resolver:
  
  

  • The Check type ensures that the login concerns a guest user.
    
    

  • In this case, a negated Role rule is evaluated, which is considered passed if a role other than the XF_GUEST role designated for Guest users is considered the Role of session.

• As the Action on passed rule, two event actions should be executed:
  
  

  • The Log message event action ensures that the incident of an 'inappropriate' login as a guest user can be traced in the error.log.
    
    

  • The subsequent Abort ensures that the formally legitimate session is terminated immediately in this case.

►NOTE◄ Since the logged out user will no longer see an error message triggered by an Abort anyway, the 'Suppress' mode is selected.

The Log message event action is configured as shown on the right:

• The static text WELCOME is input directly as the Name (as above).
  
  

• The Message with two placeholders for parameters is also created via direct input:
  
  Denied access to Guest user {0} as {1}
  
  

• The Level is defined using a Conditional value that distinguishes between two cases:
  
  

  • If a Role rule applies that uses particularly 'powerful' roles as a positive list, the Level 'Fatal' (FATAL) is assigned.
    
    

  • Otherwise, the Level 'Error' (ERROR) is assigned.
    
    

• Both Parameters in the Message are supplied with the data from the return values for User of session and Role of session.