Signed stream names never expire / authentication callback

[hotwired]

Signed stream names never expire / authentication callback

[dhh]

I think it's probably better to provide a hook into Turbo::StreamsChannel to provide authentication. Because having long-expiry tokens make them safe for caching/long-running socket connections. If you want to explore a callback in there and a configuration to go with it 👍

[MSNexploder]

Makes sense. Will look into it next week 👍

[MSNexploder]

Finally had some time to look into this but I'm unsure about how to proceed.
So here are my current thoughts.

Where should we be able to tap into using a callback?

My first idea was adding two callbacks mirroring the ActionCable connection/channel split but couldn't think of any case where the callback within the connection is necessary.
Another idea was providing generic before/after callbacks but I think the would be to broad and add unnessecary complexity.

So in the end I settled with providing a single callback into the Channel after verifing the stream name.

What type of information should we provide?

I would go with providing the actual ActionCable channel. It's public API anyways and providing only some parts of the channel (e.g. only params, cookies) will add unnecessary friction both for the user and maintainers.

I would like to provide a version of the stream name unpacked back into the provided streamables. Given how the stream name is currently generated we cannot fully restore the streamables so this could be a surprising. As of now only objects supporting global ids could be restored, everything else would just be strings. Additionally this would mean we need to escape our joining character within the streamables. At the moment we use : as joining character which often is used in #to_param (e.g. message:<id>).

Can/Should we drop signing channel names with a authentication callback in place?

No, I don't think so. Keeping signed channel names gives us another line of defense and keeps the callback an entirely optional addition. Often those signed channel names should be good enough security measure.

Alternatives to consider

Instead of providing this callback we could go the ActiveStorage route and add documentation how to override Turbo::StreamsChannel in order to provide a higher level of protection.

[dhh]

I think we might be overthinking it. We could make the StreamsChannel inherit from ApplicationChannel instead of ActionCable::Channel::Base, then all the authorization setup there would automatically apply.

[MSNexploder]

Is inheriting from ApplicationCable::Channel even necessary?
Normally some generic authorization setup would happen in ApplicationCable:Connection anyways and if I recall this correctly turbo-rails uses it automatically.

Which means we have basic authorization support out of the box - and given that something like fine-grained authorization is normally highly application specific - probably enough.

[dhh]

You're right @MSNexploder. Agree that this is where this logic should live anyway.