Last updated
Last updated
If you're just trying to bootstrap a proof-of-concept application on your local workstation, you don't technically have to worry about giving ActionCable the ability to distinguish between multiple concurrent users. However, the moment you deploy to a host with more than one person accessing your app, you'll find that you're sharing a session and seeing other people's updates. That isn't what most developers have in mind.
You can use your default Rails encrypted cookie-based sessions to isolate your users into their own sessions. This works great even if your application doesn't have a login system.
We need to instruct ActionCable to stream updates on a per-session basis:
Finally, we need to give Optimism the ability to broadcast updates to the correct channel subscription. We will override Optimism's default "OptimismChannel" with a lambda that returns the subscription identifier. You might already have other values in your initializer, or it might not yet exist at all:
We need to instruct ActionCable to stream updates on a per-session basis:
Finally, we need to give Optimism the ability to broadcast updates to the correct channel subscription. We will override Optimism's default "OptimismChannel" with a lambda that returns the subscription identifier. You might already have other values in your initializer, or it might not yet exist at all:
Many Rails apps use the current_user convention or more recently, the object to provide a global user context. This gives access to the user scope from almost all parts of your application.
If you're using the versatile authentication library, your configuration is identical to the User-Based Authentication above, except for how ActionCable looks up a user:
Practice safe optimism