Protect Customer Conversations

Test customer, guest, and staff ticket authorization, protect guest tokens, and troubleshoot private data exposed in customer-facing responses.

Support ticket privacy depends on authorization for each ticket, correct guest-token handling, and separating staff-only data from customer-facing responses. Dragwyb Click to Chat includes checks for staff permissions, logged-in customer identity, and a guest token that matches the saved ticket token. Use the checks below to verify the behavior on your own site; this article does not certify a live deployment.

Understand the ticket authorization checks

For an individual portal ticket, the REST controller checks whether the requester is an administrator or authorized support staff member, a logged-in customer associated with the ticket, or a guest with a token matching that ticket’s saved token. A ticket-specific guest token is compared with the stored value using a timing-safe comparison. A general ticket ID or an unrelated token should not be treated as authorization.

The controller also has a separate permission path for the initial ticket-list request, which can allow an empty listing for a visitor without a token. That behavior is not the same as permission to open a specific ticket or read its conversation.

Run a customer and guest access matrix

Use disposable test tickets and separate identities. Record the result for each case:

  1. Ticket owner: sign in as the intended customer and verify the account can access its own ticket.
  2. Unrelated customer: sign in with a different test account and try to open the same ticket. Access should be denied unless that account is legitimately authorized for it.
  3. Guest with matching token: verify the intended guest session can open the associated ticket.
  4. Guest without a token: open the specific ticket in a clean browser session without guest credentials and confirm access is denied.
  5. Guest with another ticket’s token: try a separate test ticket’s token against the first ticket and confirm that ticket-specific validation rejects it.
  6. Authorized staff: verify staff can access tickets only through the permissions assigned to their role.

Protect guest tokens and shared devices

  • Treat guest tokens and token-bearing ticket links as sensitive access information. Do not publish them in screenshots, public bug reports, shared documents, or chat messages.
  • Use the configured guest-session timeout and end-session control where appropriate, but do not assume the browser timer revokes a saved token on the server.
  • On a shared device, end the guest session and verify that a new browser session cannot reopen the previous visitor’s ticket.
  • Use a private window or separate browser profile for negative tests so existing browser storage does not accidentally supply a token.

Check customer-facing data and private notes

The ticket service’s customer-portal filter removes internal notes, raw ticket metadata, session identifiers, staff assignment fields, and other staff-only data from portal responses. It also removes the guest access token from ordinary public responses, with a special case for the initial response when a new guest ticket is created. The separate private-note service checks the support permission before allowing note operations.

If a customer appears to see a private note or staff-only field, reproduce the issue with a test ticket and inspect the actual customer-facing response. Review custom code, filters, overrides, and integrations that may alter portal data. Do not assume that hiding an element in the browser interface is sufficient to protect data returned by an API.

What to do if a privacy check fails

  1. Record the test identity, ticket ID, browser profile, and exact action that unexpectedly succeeded or failed. Never include the guest token in the report.
  2. Update the plugin to the version you intend to support and repeat the test with a clean browser profile.
  3. Review the ticket’s customer association and guest-token metadata through authorized administrative access.
  4. Check whether custom REST routes, filters, or theme/plugin code alter authorization or customer-facing ticket data.
  5. Do not treat the privacy workflow as verified until the unexpected access is resolved and the negative tests pass.

Related guides: Guest Ticket Access and Privacy, Configure Secure Guest Ticket Access, and Use Private Staff Notes.