Manage PubNub Guest Users
To send or receive data over PubNub, clients are required to specify a UserID (previously referred to as a UUID) when creating a new PubNub instance with any of our SDKs, including the Chat SDK. The user ID uniquely identifies the user and has several purposes:
Suppose the same person uses multiple devices (mobile, tablet, desktop) to communicate over PubNub. In that case, you want them to have a consistent experience across devices, i.e., access to the same message history, channel list, and user metadata.
Checking whether the user is online or offline using PubNub presence is tied to their user ID.
Assigning user permissions for specific channels and resources using PubNub Access Manager requires a user ID to determine who is being assigned access.
PubNub’s real-time serverless user metadata storage mechanism, App Context, requires a user ID.
For billing purposes, where we charge per Monthly Active Users (MAU), an ‘active user’ is calculated based on the number of unique user IDs.
A typical application workflow is as follows: The user creates an account and logs into your app, probably using some identity management provider (oauth authentication). After successfully logging in, your identity provider assigns them an ID. The PubNub user ID is assigned to the user by some related process: you could either reuse the ID from your identity provider or maintain a mapping between that and user PubNub IDs.
This process breaks down for guest users because you cannot uniquely identify each guest user. For clarity, a ‘guest user’ can use your app without ‘logging in’, perhaps clicking on a ‘continue as guest’ button. How can you ensure that guest users only have access to the channels and resources they are allowed to? How can you ensure that guest users do not negatively impact your PuNub bill? This article attempts to answer these questions.
There is no single best approach to managing guest users across all use cases, but most of our customers opt for one of the three options below:
Option 1: Create a new ID for each guest user
This is the simplest option: create a random string whenever you need to make a guest user and provide that as the user ID to initialize the PubNub SDK. When assigning access, your server logic would need to determine that this is a guest user (perhaps by prepending the ID with ‘guest’) and assign read / write access to a standard set of permitted public channels and resources to each guest.
Advantages:
This is very easy to implement: generate a random string and provide that as the PubNub user ID.
Disadvantages:
If you have a high percentage of guest users, this approach could significantly inflate the number of billable users, so it would not be viable for customers on MAU billing who expect a high number of guest users. Your application is also more susceptible to malicious attacks since a bad actor creating many guest users would result in a large PubNub MAU count.
As guest users revisit your application, they will receive the ‘new user’ experience every time. Depending on your application, this could lead to user frustration as they lose all context and you could not offer a cross-platform experience.
You lose any benefit from PubNub Insights (or other analytics software) since you have no context for your guest users.
Option 2: Maintain guest user ID across sessions
This approach tracks the guest user as they repeatedly log in on the same device. This can help you identify returning users and enable you to reuse user IDs for these users.
For browser-based JavaScript applications, session cookies can track users visiting and revisiting your application. For native applications such as Android or iOS, the platform will often have some way of identifying the user in a privacy-friendly way; for example, all platforms offer local app storage, which could be used to check whether the user has logged into your application before.
Advantages:
This is also an easy solution to implement: check for a ‘userId’ in the browser’s cookies or the application’s local storage. If no ‘userId’ is found, generate a new one; else, reuse the existing one.
Since returning users can be identified, you can start to build up some context for guest users, so even though your data will be anonymous, you can still glean some analytics from guest user behaviour.
This approach can mitigate against MAU inflation and reduce costs compared to option 1, but is not infallible (see disadvantages, below)
Disadvantages:
This solution is not foolproof since session cookies are not remembered when visiting in ‘incognito’ mode, and native application storage will not persist across app uninstalls / reinstalls. Further, you cannot track users across devices, so you still cannot identify the same user logging into multiple devices (mobile, tablet, desktop).
Remember also that cookies are not inherently secure, so you should not ‘trust’ that returning users are always who they claim to be. For example, you should not restore any previous message history.
Option 3: Allocate from IDs from a ‘guest user pool’
By maintaining a pool of ‘guest user IDs’, you can maintain tight control over user ID allocation at the cost of increased complexity.
When a guest user needs an ID, your client will request a ‘guest ID’ from a pool of predefined IDs managed by your server. Your server logic (or a PubNub Function API) will need to find a guest ID not currently in use and return that to the client. Whilst conceptually simple, there are several edge cases you need to consider: How do you determine when a ‘guest ID’ is no longer in use? Would you log the client out after a while? What if there are no available guest IDs?
Advantages:
This approach gives you the tightest control over guest ID allocation—you always know the maximum number of MAUs and have predictable PubNub billing. This solution is easy to secure using PubNub Access Control since you need to assign access to only a finite number of IDs.
Disadvantages:
This solution is the most complex of the three to implement; logic on your server (or a PubNub Function) would be needed to maintain and manage the list of ‘guest IDs’. Further, it would be impossible to get guest analytics, since a relatively small number of IDs are shared amongst all guest users.
Conclusion
No single PubNub guest user ID generation approach will work for all applications.
Some questions to ask yourself when deciding how to manage guest IDs:
How many guest users do I expect?
Do I expect the majority of my users to log in?
How much development time can I allocate for guest user management?
Most applications would probably benefit from a phased approach, starting with the simplest option (1), and working their way to the most secure option (3) as your application exits its beta phase. Additionally, it is common to implement a design pattern that encourages users to create an account instead of remaining anonymous.
For more advice, please contact either our presales or devrel teams, who are happy to help.
