未注册用户的Realm PermissionOffer机制及建议工作流咨询

Great question—this is a really common use case when building collaborative apps with Realm, so let’s walk through your questions one by one.

How does PermissionOffer work when the user ID doesn’t exist? #

By default, PermissionOffer is designed to target existing user IDs in the Realm Object Server. If you try to create a PermissionOffer for a user ID that doesn’t exist yet, the server won’t retain that offer or associate it with a user who registers later. The offer will essentially be ignored because there’s no user record to bind it to. So you can’t just send an offer to a non-existent ID and expect it to kick in once the user signs up.

Can PermissionOffer wait for a user to create an account if the user ID is an email address? #

Short answer: No, not out of the box. Even if you use an email address as the user ID (like when using the Email/Password authentication provider), the Realm server doesn’t track "pending" offers for unregistered emails. When you create a PermissionOffer, it needs a valid, existing user ID to attach to. Until that user registers and their ID exists in the server’s user database, the offer won’t have a target to apply to.

Recommended Workflow for This Scenario #

To make this work, you’ll need to add a layer of "pending share requests" that bridges the gap between the existing user’s share action and the new user’s registration. Here’s a solid, reliable approach:

• Step 1: Store pending share requests in a dedicated Realm
  When an existing user wants to share a Realm with an unregistered email, don’t create a PermissionOffer right away. Instead, save a share request to a centralized "Share Requests" Realm. This request should include:

  • The URL of the Realm to share
  • The desired permission level (read-only, read-write, etc.)
  • The target email address
  • The ID of the user initiating the share

• Step 2: Trigger permission grant on new user registration
  When the unregistered user signs up using the target email, you need to check for any pending share requests tied to their email. This can be done either:

  1. Client-side: After the user successfully logs in, query the "Share Requests" Realm for entries matching their email. For each request, create a new PermissionOffer (or use PermissionOfferResponse if you want to let the new user accept/reject) targeting their newly created user ID.
  2. Server-side (preferred): Use Realm Functions to automate this. Set up a function that runs whenever a new user is registered. The function will query the "Share Requests" Realm for matching emails, then create and apply the necessary PermissionOffers automatically. This is more reliable because it avoids relying on client-side logic.

• Step 3: Clean up and notify users
  Once the permission is granted, mark the share request as "processed" in the "Share Requests" Realm. You can also send notifications to both the sharing user and the new user to confirm the share is active.

Bonus Tip #

If you want to let the new user accept or reject the share instead of auto-granting it, replace the direct PermissionOffer with a PermissionOfferResponse workflow. The pending request would trigger an offer that the new user can accept through the app, which then applies the permissions.

内容的提问来源于stack exchange，提问作者KMLong