Secure Guest Ticket Access

Guest ticket access lets a visitor create and continue a support request without signing in to WordPress. Dragwyb Click to Chat uses a guest access token associated with the ticket and stores the active guest session in the browser. Configure the portal settings carefully and test the access flow with a test ticket before relying on it for customer support.

Review guest access settings

In the Support Portal settings, review the guest ticket form, guest session timeout, browser storage mode, expiry timer, end-session button, public-device notice, and guest media-upload restriction. In version 1.2.0, the default guest session timeout is five minutes and the default storage mode is session. The timeout can be configured from 1 to 1,440 minutes; saved values on your site may differ.

Session storage: keeps the active guest session in browser session storage. This is the default mode.
Local storage: can retain guest-session data beyond the current tab, so assess whether it suits your users and device environment.
Expiry timer: shows the configured client-side session countdown when enabled.
End Guest Session: gives the visitor a control to clear the guest session from the browser.
Public-device notice: can remind visitors to take care when using a shared computer.

Understand token-based authorization

When a guest ticket is created, the ticket service generates or stores a guest access token with the ticket. The portal includes the token with guest requests. For a specific ticket, the REST controller compares the supplied token with the saved ticket token and uses a timing-safe comparison. Staff permissions and logged-in customer identity are checked through separate authorization paths.

The browser timeout is a client-side session expiry mechanism. Do not describe it as automatic server-side token revocation: the source reviewed for version 1.2.0 does not establish that the timeout deletes or invalidates the saved ticket token. A guest token should therefore be treated as sensitive access information for as long as it may authorize a ticket.

Test access in separate browser sessions

Create a test ticket while logged out, using a dedicated test email address.
Verify that the intended guest session can open and interact with its ticket.
Open the same ticket from a separate private window or browser profile without the token and confirm that access is denied.
Try a different test ticket’s token against the first ticket and confirm that ticket-specific authorization denies access.
Use End Guest Session if enabled, then confirm the browser no longer resumes the previous guest session.
Wait beyond the configured client-side timeout and verify the portal’s browser behavior. Separately test server authorization rather than assuming the timer itself revokes the token.

Do not run these checks against a real customer’s ticket, and do not paste guest tokens into public bug reports, screenshots, or support messages.

Common troubleshooting checks

The guest cannot reopen a ticket: confirm the browser session has not expired or been cleared, and use the intended guest access flow.
The wrong ticket appears or access is denied: verify the token belongs to the intended ticket and repeat with a clean browser session.
A shared device retains a session: review the storage mode and timeout, use the end-session control, and close the browser session after testing.
Guest uploads are unavailable: review the guest media-upload restriction. In the inspected source, the portal only enables the media button for logged-in users with the WordPress upload_files capability and when the restriction is disabled.

For the broader privacy checklist, see Guest Ticket Access and Privacy and Protect Customer Conversations.