Issue

In applications using the SAML module, a runtime exception resembling the following stack trace occurs during a login action:

java.lang.IllegalArgumentException: Ids should not be null
at com.mendix.basis.component.InternalCoreBase.retrieveId(InternalCoreBase.java:771)
at com.mendix.basis.session.PersistentSession.<init>(PersistentSession.scala:29)
at com.mendix.basis.session.PersistentSession.<init>(PersistentSession.scala:37)
at com.mendix.basis.session.SessionFactory$.createPersistentSession(SessionFactory.scala:80)
at com.mendix.basis.session.SessionManagerBase.getSessionById(SessionManagerBase.java:234)
at com.mendix.basis.component.InternalCoreBase.getSessionById(InternalCoreBase.java:217)
at com.mendix.core.Core.getSessionById(Core.java:1468)
at saml20.implementation.security.SessionManager.evaluateActiveSessions(SessionManager.java:568)
at saml20.implementation.security.SessionManager$1.run(SessionManager.java:166)

Environment

SAML (all versions)

Cause

This runtime exception occurs in an application with the SAML module when the following conditions are met:

• The user has a session cookie in their browser;

• PersistentSessions are enabled. This custom runtime setting defines whether sessions will be persisted in the database or not and can be enabled/disabled in as mentioned in the Runtime Customization documentation (This condition only applies to Studio Pro 8. User sessions are persisted by default from Studio Pro 9 onwards);

• The user has been deleted from the database.

When the conditions above are met, the user session (System$Session object) still exists in the database, but not in the runtime memory, as the reference to the user in the session object gets cleared during deletion. When the user loads the app in their browser, the app performs a GetSessionDataAction XAS network request.

The runtime detects that the user has a cookie, so it requests the session object from the database because it is not in memory anymore. The runtime finds the session record in the database and tries to load the related user to create the session object again (which would then be put in the memory again).

Since the user object was deleted, the runtime tries to load a null id and this generates the stack trace.

Solution/Workaround

The solution is to create a microflow that retrieves all System$Session objects that have no reference to a user and delete those System$Session objects. Then add this microflow to the start-up microflow.

Additional information 

Mendix documentation:

• SAML
• Runtime Customization