Guest users
See also: Users
What are guest users used for?
Typically, accounts for Guest users are created automatically (see Create guest user) in order to provide access to selected content or functions via the Lobster Data Platform with the lowest possible threshold in terms of content and, if necessary, time-limited access without authentication.
In the field of logistics, accounts for Guest users are frequently used for shipment tracking by (end) recipients who should not be directly ‘invested’ as Users of the Lobster Data Platform for this purpose.
The Guest users menu item can be found in the Hauptmenü via the ‘Administration/Accounts’ menu node, provided sufficient permissions are available.
This opens an overview for the ‘Guest user’ (GuestUser) entity type by default, which is also referred to as a guest user account.
View name: de.lobster.scm.base.security.guest::GuestUser|listDetailsWindow
Menu node name: admin/accounts/guestUserOverview
Access to Guest users is regulated by the permissions for the ‘Administration/Accounts/Guest users’ node (administration/accounts/guestUser).
The Guest users menu item only appears if the permission for ‘Show’ (show) is available for Guest users.
Access to Guest users is generally subject to owner restrictions for the Firma der Session.
The permissions of the Rolle der Session are therefore only applicable in relation to Guest users for whom the Firma der Session is considered the ‘owner’ or is the recipient of corresponding Firmenfreigaben.
A guest user account enables a Lobster Data Platform session to be set up without explicit authentication. It is then considered a User of session within the session.
►NOTE◄ If Guest users perform write accesses to entities, the negative value of the ‘ID’ (id) of the account is entered in the ‘Creator’ (creatorId) or ‘Last modified by’ (lastModifierId) field in order to distinguish between references to Guest users and Users.
CAUTION
Guest users are a potential security risk, as they allow access to the Lobster Data Platform without explicit authentication and are typically ‘provided’ automatically and without authorisation by an administrator.
'Unchecked’ access should therefore be strictly controlled using the following methods:
Guest users should only have access to highly restrictive Roles that only grant the minimum scope of permissions for the specific purpose.
If necessary, specific functional restrictions for Guest users can be configured by evaluating a Check type for the User of session (e.g. in Association criteria or Event handling).
The use of Guest users accounts can and should be limited in time or to a maximum number of logins via specific properties (see below).
By defining specific guest user restrictions, access to specific entities for individual accounts can be controlled more precisely than is possible for Users (see Create guest user).
The following table lists the main systematic differences for Guest users and Users:
|
Subject |
||
|
Identification |
'ID' (id)/'Login token' (loginToken) |
'ID' (id) / 'Username' (username) |
|
References in entity attributes |
Negative value of the ‘ID’ (id) |
'ID' (id) |
|
Contact details |
‘E-mail address’ (emailAddress) only |
Complete address (see Addresses) |
|
Authentication |
Not required |
Required |
|
Unique ‘role’ (role) as a required field |
Selection at login, if assignment is ambiguous |
|
|
Unique ‘company’ (company) as a required field |
Selection at login, if assignment is ambiguous |
|
|
Duration of the account |
Optionally limited by ‘Valid to’ (validTo) |
Unlimited (password expiry date only) |
|
Max. logins |
Optionally limited by ‘Max. logins’ (maxLogins) |
Unlimited |
|
|
|
|
|
|
|
|
|
Custom data |
|
|
|
Individual access control |
|
|
not provided
optionally availableBy default, the interactive administration for Guest users is based on a combined view (listDetailsWindow), which can be opened via the Guest users menu item in the Hauptmenü.
The following screenshot shows the default ribbon (for a role with all relevant permissions), including the default input form with the details of the guest user selected in the list area (at the bottom).
Special features in the ribbon
In addition to the generic ribbon buttons (New, Delete, etc.), the main category (‘Common’) visible in the screenshot also contains specific ribbon buttons for Guest users :
|
Sub category |
Ribbon button |
Description |
|
Custom data |
|
The Edit ribbon button (in the Custom data subcategory) opens a simple XML editor that can be used to view or edit customised content for a guest user account selected in the list area in the ‘Custom data’ (customData) field.
In the example, the ‘Custom data’ (customData) field contains a ‘client object’ with two fields, one of which (randomToken) contains a character string ‘randomly generated’ using a Random text token resolver, while the other (created) sets the time as the ‘date with time’ at which this string was created. Typically, such content is provided automatically, often by a mechanism that also automatically creates the entire guest user account. |
|
Login history |
|
The Show ribbon button opens a modal full-screen window (see Anmeldungsverlauf) within the current view, which lists the login history of a guest user selected in the list area. |
Contents of the default input form
The data input form provided as default for Guest users maps the contents of the data structure relevant for direct interactive maintenance for Guest users using Formularelemente.
|
Field |
Data field path |
Example values |
Contents |
|
Active |
active |
$true (Boolean) |
The Active checkbox must be ticked so that a guest user account can be used to log in to a session. |
|
Login token |
loginToken |
'b017f3e8-ec62-4e2b-be24-2bcac7e8d49e' |
The character string assigned as the Login token is typically generated randomly. In the context of the input form, this is made possible by the Button with the key symbol (tooltip: ‘Generate’) to the right of the input field on request. Alternatively, a character string can be entered directly instead of generating a login token. When clicking on ‘Save’, the system checks whether the specified Login token is unique and refuses to update or change a guest user account if the character string is already in use. If a new guest user account is created as a copy of an existing one, the copied login token must be replaced before saving. The Login token (required field) is the key that identifies Guest users when they log in to a session. If it is not provided via URL parameters (loginToken) when the client is started, it must be entered or inserted in the login screen for Guest users as the ‘Login token’. |
|
Company |
company |
'ZWORX Ltd.', 'Hidden company' |
Single selection for the predefined Company of session for each subsequent login with the Login token. |
|
►NOTE◄ The ‘Hidden company’ label appears for companies that are already assigned and can therefore be removed in the context of the current session but cannot be selected again afterwards. ►IMPORTANT◄ A guest user account that relates to a ‘Hidden company’ can be changed but not created. This is particularly relevant when copying an existing guest user account. If necessary, all hidden companies must be removed so that the copied guest user account can be saved. For access to Companies/Clients for the Company selection for Guest users, the following scenarios must be distinguished by default:
|
|||
|
Role |
role |
'Guest', 'Hidden role' |
Single selection for the Role of session for each subsequent login with the Login token. |
|
►NOTE◄ The label ‘Hidden role’ appears for Roles that are already assigned and can therefore be removed in the context of the current session but cannot be selected again afterwards. This applies to all Roles that cannot be accessed with the Rolle der Session. ►IMPORTANT◄ A guest user account that refers to a ‘Hidden role’ can be changed but not created. This is particularly relevant when copying an existing guest user account. If necessary, all hidden roles must be removed so that the copied guest user account can be saved. |
|||
|
Locale |
locale |
'German' (de) |
Single selection for the Current locale for each subsequent login with the Login token. |
|
E-mail address |
emailAddress |
'mika.spilikins@doma.in' |
A required field for specifying a character string whose suitability as an E-mail address is not checked by Validators. ►NOTE◄ Typically, Guest users are created automatically (see Create guest user), whereby the Login token is generated and sent to the specified e-mail address when the account is created. |
|
Max. logins |
maxLogins |
5 |
The Max. logins field defines the maximum number of times the guest user account can be used to log in to a session. The number 0 is interpreted as ‘unlimited’. |
|
Login count |
loginCount |
3 |
The read-only field Login count shows the logins already performed (‘used’) for the guest user account. Logins are only permitted as long as the Login count has not yet reached the limit value (>0) for Max. logins. If required, this limit can also be adjusted subsequently. |
|
Max. concurrent sessions |
maxConcurrentSessions |
1 |
This setting determines how many Lobster Data Platform sessions a guest user may use simultaneously. This restriction is checked at each login attempt. If a user exceeds the personal limit with an additional session, the new session will only be logged in if the user agrees to log out of an existing session. ►NOTE◄ The input is limited to values >0. The default value is 1. |
|
Valid to |
validTo |
22.05.2025 22:00 (UTC) |
In the Valid to field, the duration of the guest user account can be limited by specifying an absolute point in time as the ‘Date time’ (DateTime), after which no new login is permitted for the Login token. Without any information in this field, the Login token can be used for logins without a time limit. |
Guest user login
Typically, Guest users receive access to the Lobster Data Platform via E-mails with a link containing the Login token as URL parameters, which could look like this, for example:
https://platform.doma.in?loginToken=b017f3e8-ec62-4e2b-be24-2bcac7e8d49e
Alternatively, a guest user login can also be carried out interactively:
|
Starting from the default login (for Users), a context menu must be opened via the cogwheel symbol (top right). Selecting the Guest login menu item switches to the login for Guest users (see below). Conversely, it is also possible to switch back to the Users login in the same context menu. |
|
|
For the login for Guest users, only the Login token is required, which must be entered or pasted into the relevant text field to log in. The character string entered must match exactly (case-sensitive) the value in the 'Login token' field for an active guest user account in order for the login to work. Whether it is permitted may depend on other settings for the account (see table above). |
|
Configuration example
In the following example guest user accounts are used to grant limited reading access to specific shipments, based on individual restrictions for each guest user account defined by the following parameters:
On the one hand, shipments should only be listed if modified within a limited time horizon before the current time.
On the other hand, a text attribute 'Plant' of the shipment, which defines the relevance of a shipment for the guest user, should be matched against a specific filter criterion.
Further restrictions regarding the visibility result from the context of the company account predefined for the guest user account and definitions for ownership, involvement and Effective authorizations – without any dedicated configuration in the current context.
The relevant guest users are assigned a role that grants the following permissions only:
Business objects/Shipments/Read
Business objects/Shipments/Show details
Further, a special shipment overview is configured (see Custom overviews), with a condition processing the mentioned parameters per guest user account. These parameters will be stored as 'Custom data' in the guest user account and are defined in a portal, that is opened as a modal dialog from a guest user overview by clicking the ribbon button (command 'Portals > Open portal'), provided a single selection identifies the guest user to update:
When the portal is opened, data from the selected guest user account is automatically included if the form design includes a container pointing to 'loadedItem' as a data field. In our example, this container features the elements ID (data field: id), Login token (loginToken) and E-Mail (emailAddress).
Below, a filter for Plant (data field: PLANT_FILTER) can be defined by Combobox (with the key values A120, A121, A125, A127 and A12_ represented as options). The selected value is referred (as shown later) by the LIKE condition defined for the text attribute Plant (t_PLANT.value.text) in the custom overview.
To the right of the plant filter options, a date picker labelled modified as-of ... (data field: MINDATE) specifies the time horizon by setting an earliest date matched against the lastModified timestamp of a shipment by a 'Greater or equal' constraint for the custom overview.
Both filter criteria are elements of a container 'filters' (not visible in the screenshot), to facilitate handling of the combination in configurations (see below).
Clicking the Save restrictions button triggers a Custom action event 'Guest user – set data' (SET_GUEST_USER_DATA) behaviour to kick off the following event handler:
Since the Triggering events will exclusively be addressed from the portal, the only Validating rule included here is a sub-criterion checking the proper context for executing the actions (Company rule, Role rule).
All Actions will be executed in the context of the guest user account selected. This account is resolved from the variable 'formData' (of the 'Client object' type) of the portal within the Execute with action. For this purpose the content of container 'loadedItem', representing the selection, is processed by an Input object (type safe) resolver returning the 'Guest user' object.
Finally, the value of the 'Custom data' (customData) object property of this account is set by a Set value action, which transfers the settings from the 'filters' container in the portal provided in the 'formData' variable.
The Save changes later action ensures that this change in the guest user object is saved although the object was only added via Execute with.
The result of an assignment of filter criteria by this method can be verified, e.g. by clicking the 'Custom data > edit' button in the guest user overview:
In the custom overview Shipment overview (Guest user) condition, the filter criteria are then included as follows:
The text attribute 'Plant' (t_PLANT.value.Text) is matched by LIKE against the choice for 'Plant' (PLANT_FILTER).
For this purpose, the User of session is identified and the corresponding guest user account resolved by Input object (type safe).
Guest user object property 'Custom data' (customData) provides the object (object) generated from portal data including fields (property) PLANT_FILTER (string) and MINDATE (DateTime).
As shown, another Object property resolver retrieves the value of PLANT_FILTER for matching.
The MINDATE property is accessed by the same method to match against the lastModified timestamp (below).
Use example results:
The following screenshot shows example results for a guest user with access to all plants of 'Group A-12' (filter criterion: [Plant] LIKE 'A12_') modified 06/01/2019 or later.
In contrast, another guest user will see the following result based on the permission for plant 'A120' only, but an extended time horizon starting from 01/01/2019:
