Deepchat bot doesn't work for anonymous user

The CSRF token must stay for security reasons, this sounds like a caching issue or that a session perhaps needs to start. We have it working for anonymous users on other websites.

Could you answer if you have bigpipe installed and what caching/cdn modules you might have installed, so we can try to replicate this.

Thanks for your quick response! Indeed, after removing the CSRF token, loading the bot and then re-adding the token, the bot still works. So it's something to do with caching or timing.

The problem is in a local DDEV container using:
* Internal Dynamic Page Cache
* Internal Page Cache

@dotist @marcus_johansson We have the chatbot working for anonymous user. I tried without the patch and its working for both authorized and anonymous user.

As an idea, maybe CSRF token should be passed by the client in a header instead? At the moment the cache max age is set to 0 only because of this token in the url, right? Or is there any other reason to have the block itself non-cacheable?

The client (JS part) can obtain the token by visiting the url session/token and then use it in X-CSRF-Token. This way there will be no need to url to have the token as query parameter.

Maybe I am wrong, of course.

turns out that my problem was actually the Cookie/Shield in the Brave browser... Maybe there could be a notification to the user when something like this is detected?

So there was a general known issue with Drupal core, that if no sessions is started the csrf token simply does not work, see 🐛 CSRF check always fails for users without a session Needs work .

I have added so when the chatbot is created, it will generate a session if it doesn't exist, and then generate a new csrf token in the same call. This will then via js reset the connect parameter to use this.

Performance wise this makes it possible to remove the complete none-cache of the block and set it per user instead, but this also means that a new session will be created for any anonymous user where the block is loaded.

I did fix a minor bug issue here as well connected to loading styles, that got fixed here as well.

Please test and review the code.

Looks good now, thanks Marcus!

Thanks @andrewbelcher for review. Getting merged.

Automatically closed - issue fixed for 2 weeks with no activity.

In our frontend we override deepchat-init.js because of custom UI needs. Because of such cases, it would be nice if the session js was separate from the UI js, so that when overriding, one don't have copy over the session logic as well. See patch.