If the page you redirect users to does not invoke the CrowdHandler integration then you run the risk of breaking the user’s session and sending them back to the Waiting Room.
This is a particular issue when:
Other integrations could experience this issue:
- You are using a custom integration on the server, but you have redirects set up to run before the integration can run, e.g. on the CDN, or in an .htaccess file.
- You are using the Wordpress plugin, but you have redirects set up in an .htaccess file, an Nginx configuration a or on a CDN.
When the user is sent to your redirect page, their token is encoded in a ch-id parameter and passed to your site in the url.
The CrowdHandler integration retrieves this parameter and saves it on the users’s browser using local storage.
If the first page you send the user to does not have the CrowdHandler integration, and does not forward the ch-id to the next url, then the user's session will be lost before it be set. This typically happens when the url you send the user to immediately redirects to a second url. If the token is not passed with the redirect, this will result in the user being given a new token and being returned to the queue.
Depending on your use case there are solutions.
- If your landing page immediately redirects the user, you need to ensure your redirect forwards the ch-id parameter. This may happen, for example, if you have an index page that automatically redirects to a language, e.g. /en becomes /en?ch-id=tok_xxxxxxxxxxx If you can configure your redirect rule to forward all query parameters do that.
- If your landing page immediately redirects the user, e.g. from / to /tickets, and /tickets has the CrowdHandler integration, but your landing page does not, then consider making your redirect /tickets instead of /
- If your landing page is, for example https://your-domain.com/tickets but your web server silently redirects the user to https://your-domain.com/tickets/ then enter the full url with the trailing slash as your redirect page.