throw :forbidden

[leastbad]

Type of PR (feature, enhancement, bug fix, etc.)

Feature

Description

Introduces a new authentication primative that provides a flexible, unopinionated mechanism to disallow Reflexes from being run when the user does not have permission to do so.

Functionally, it works very similarly to using throw :abort in a before callback to halt a Reflex. Developers can use throw :forbidden and it will halt the Reflex in the same way :abort does, but instead of triggering a halted life-cycle on the client, there is now a forbidden life-cycle stage, with all corresponding callbacks and events.

As with all Reflex types, any payload values defined before the throw statement are delivered to the client. The developer can optionally use the payload to deliver information about why the Reflex was prevented from running.

This feature does not make any attempt to decide what constitutes an authentication violation; it is expected that this logic is best handled in plugins or the application itself.

Templates have been updated, and I took the opportunity to further simplify the client-side logging module.

Why should this be added

Action Cable Connections can persist longer than the current user session, which poses significant security complexity to over-the-wire applications. This is especially true given that modern use cases often see users logged in from multiple tabs and multiple devices simultaineously.

It is no longer enough to just refresh the page, as the user could logout on another tab and today, the current tab would continue running Reflexes as the logged out user. This is unacceptable.

I am preparing to release a new gem which will provide easy, Devise-like authentication checking. I would very much like an API surface to plug into to provide this functionality.

Checklist

• My code follows the style guidelines of this project
• Checks (StandardRB & Prettier-Standard) are passing
• This is not a documentation update