ContentAccessToken is Site Store Pro’s mechanism for granting secure, time-limited access to gated CMS pages after a customer completes a purchase. Instead of requiring every buyer to register an account or stay logged in, the system generates a unique UUID magic link and emails it to the customer. When they visit the link, they are automatically granted access to the protected content — no password required.
Token Generation
Tokens are created automatically when an order reaches thecompleted status. You do not call this manually for standard flows — the order lifecycle triggers it.
generateOrRefresh() either creates a new token or refreshes an existing one (resetting expires_at to 90 days from now). Admins can also trigger a refresh manually by clicking Send Download Reminder or using the resend email action on the order — both call generateOrRefresh() and dispatch a fresh link to the customer.
Redemption URL
1
Validate the token
The system looks up the
uuid in the content_access_tokens table and confirms it exists and has not passed its expires_at timestamp.2
Push purchase proof to session
On a valid token, the system pushes the associated
product_id into session('verified_purchased_products'). This session key is what gated CMS pages check to determine whether to display their content.3
Redirect to content
The customer is redirected to the
completion_redirect URL configured on the product. This is typically the gated CMS page URL itself, which the customer can now view because the session is populated.Token Expiry and Refresh
By default, every token expires 90 days from its generation date. Theexpires_at column stores this timestamp.
Refreshing a token via the admin resend action does not invalidate the previous UUID — it updates the same record. The old link URL continues to work with the new expiry date.
Guest Access
Customers who check out as guests — without creating an account — are fully supported. Because the magic link redemption flow writes purchase proof to the session (not to the user account), a guest purchaser who clicks their emailed link receives the same seamless access as a logged-in customer. This design means you do not need to force account creation at checkout to sell gated content. The token carries all the proof needed.CMS Page Gating Flow
When a CMS page hasrequired_product_id set, every visitor goes through the following access check:
1
Visitor arrives at the gated page
The CMS page controller reads the
required_product_id configured on the page record.2
Access check — three conditions evaluated in order
The system grants access if any one of the following is true:
Condition A — Logged-in verified purchase
The visitor is authenticated and their account has a verified purchase of the required product on record.
Condition B — Session purchase proof
The visitor’s session contains
verified_purchased_products with the required product_id — set by a previous magic link redemption in this browser session.Condition C — Valid magic link UUID in URL
A valid, non-expired UUID token is present in the URL and resolves to the required product. The token is redeemed on the spot, populating the session and redirecting.
3
Access denied — show purchase gate
If none of the three conditions are met, the system displays a lock screen or purchase gate prompting the visitor to buy the product.
Database Schema
Thecontent_access_tokens table stores one record per customer–product pairing.
string
A cryptographically secure random UUID. This value is the token embedded in the magic link URL:
/content-access/{uuid}.integer
Foreign key to
users.id. References the purchasing customer’s account. For guest purchases, this may reference a guest user record created at checkout.integer
Foreign key to
products.id. Identifies which product purchase this token represents access proof for.timestamp
The UTC timestamp at which this token becomes invalid. Defaults to 90 days after creation. Reset to
now() + 90 days on every generateOrRefresh() call.