• Tutorials

Managing user sessions

When integrating an embedded service, it is important to ensure users can return to their session without losing progress. The uid parameter in the mmob SDK plays a key role in this by associating users with their session data. Without it, every visit (including page refreshes) can result in the loss of user specific information.

What is a uid?

The uid is a unique identifier assigned to each user, allowing the embedded service to recognise them across visits. It ensures that user specific data, preferences, and session state can be maintained throughout their interaction with the application.

How uid Works

To ensure user sessions persist across visits, pass a uid when initialising the SDK.

Example SDK initialisation

mmob.init({
  deployer_id: "your-deployer-id",
  integration_id: "your-integration-id",
  location: "#app-container",
  owner_id: "your-owner-id",
  uid: "user-123456", // Unique user identifier
});

If a uid is not specified during initialisation, the SDK will generate a temporary identifier for the user. However, this identifier is only valid for the current session.

This means that:

  • The user will be treated as a new visitor each time they refresh the page or return later.
  • Any session data or preferences set during their visit will not be retained.
  • The embedded service will not be able to associate them with any previous interactions.

Example use case

Imagine you are embedding a financial dashboard into your application. This dashboard shows users:

  • Their linked accounts
  • Their preferred currency
  • Their last viewed report

When a user logs in, they expect to see their data immediately and not have to reconfigure everything each time.

If the SDK is initialised without a uid, the embedded service has no way of recognising them when they reload the page or open the application again. Their preferences and previous activity will be gone, forcing them to start from scratch.

⚠️ Warning! Risks of incorrect uid usage

Using incorrect values for uid can lead to session conflicts, unintended data exposure, and security risks.

  • Do not use generic or shared values like "guest", "anonymous", or "default-user". This can cause multiple users to be assigned the same session, leading to incorrect data being displayed.
  • Never use an email address that is shared across multiple users. This could expose sensitive data to the wrong person and compromise privacy.
  • Avoid dynamically generated session-based identifiers that change on every visit—this prevents user sessions from persisting across page loads.
  • Ensure that each uid is unique per user and remains consistent across sessions. This helps maintain security and ensures a seamless user experience.

If a uid is improperly assigned, users may access the wrong session, leading to data leaks, privacy violations, and unpredictable behaviour within the embedded application.

Best practices

  • Always pass a uid when initialising the SDK to ensure session persistence.
  • Use the same uid consistently across sessions to maintain user recognition.
  • Ensure uid is unique per user to prevent session conflicts.
  • Do not change uid mid session, as this may cause the user to lose their session state.

Ensuring a unique uid

The uid should be unique to each user to prevent session conflicts and ensure accurate user recognition. It acts as a distinct identifier that links the user to their session data within the embedded service.

Examples of suitable uid values

A uid can be any value that uniquely identifies a user, such as:

  • An email address: "user@example.com"

  • A user ID from your database: "user-123456"

  • A hashed identifier: "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"

  • A phone number (if applicable): "+447123456789"

Making sure that the uid is both unique and persistent, users can have a seamless experience without losing their session state.

Was this page helpful?