ActionPolicy authorization during broadcast Turbo Streams using Devise

[danielnc]

I have some partials that are broadcast thru action cable during model creation/update

For example: after_create_commit -> { broadcast_append_later_to "posts", target: "post-list", partial: "post", locals: { post: self } }

Problem is that the partial is checking if the user is allowed to see a specific UI element

ruby

<% if allowed_to?(:upvote?, post) %>
	<%= link_to "Upvote", upvote_post_path %>
<% end %>

I am getting the following exceptions

Make sure that your application is loading Devise and Warden as expected and that the Warden::Manager middleware is present in your middleware stack.
If you are seeing this on one of your tests, ensure that your tests are either executing the Rails middleware stack or that your tests are using the Devise::Test::ControllerHelpers module to inject the request.env['warden'] object for you.```

How do I inject the current_user in the broadcast_append_later to be used by action policy? I have the current user in a thread-safe object(Current.user) but not sure how to broadcast rendering partials that depend on action policy specific authorization methods

[palkan]

Hey!

How do I inject the current_user in the broadcast_append_later to be used by action policy? I have the current user in a thread-safe object(Current.user) but not sure how to broadcast rendering partials that depend on action policy specific authorization methods

It's almost impossible with Hotwire. The problem is that the Turbo Stream partial is rendered without any user context (it's rendered within a background job and once for all users). What you need is to render a partial per user.

There are several ways of dealing with this problem (I call it the personalization problem, see this talk):

• Enhance UI on the client-side via Stimulus (or similar); render controls hidden by default and show them only when the current user id matches the author id — not so good, since you basically duplicate the authorization logic; acceptable if it's simple. See the last part of this article: https://evilmartians.com/chronicles/hotwire-reactive-rails-with-no-javascript

• Use brand new Turbo Page Refresh feature (Turbo 8 is still alpha or beta, but you can build your own following the instructions from this post: https://evilmartians.com/chronicles/the-future-of-full-stack-rails-turbo-morph-drive); in this case, Turbo Stream only delivers signals, and clients perform additional AJAX requests to refresh their UI

• Finally, it's possible to use stream interceptors (in theory) and move signaling to the server (see this slide: https://speakerdeck.com/palkan/railsconf-2022-the-pitfalls-of-realtime-ification?slide=44); that would require having different channel classes for different streams