CHANGELOG
Changelog
v2.0.0-dev
Canary 2.0.0 introduces authorization hooks for Phoenix LiveView. The Plug based authorization was refactored a bit to make the API cosistent. Please follow the Upgrade guide to 2.0.0 for more details.
Enhancements
- added support for authorization LiveView with
Canary.Hooks - added
:error_handlerand ErrorHandler behaviour - added
:requiredoption, default to true
- added support for authorization LiveView with
Dependency changes
- Elixir ~> 1.14 is now required
Deprecations
- The
:non_id_actionsoption is deprecated and will be removed in Canary 2.1.0. Use separate:authorize_resourceplug fornon_id_actionsand:exceptto exclude non_in_actions. - The
:persistedoption is deprecated and will be removed in Canary 2.1.0. Use:requiredinstead.
- The
v1.2.0
- Enhancements
- Add
requiredopt
- Add
v1.1.0
- Enhancements
- Add
non_id_actionsopt
- Add
v1.0
- Bug fixes
- Do not clobber resources in the
Connon index action if they are of the same model
- Do not clobber resources in the
v0.14.2
- Relax Ecto version requirements
v0.14.1
- Bug fixes
- Use Macro.underscore/1 instead of Mix.Utils.underscore/1 to avoid :mix dependency on production
v0.14.0
- Enhancements
- You can now tell Canary to search for a resource using a field other than the default
:idby using the:id_fieldoption. Note that the specified field must be able to uniquely identify any resource in the specified table.
- You can now tell Canary to search for a resource using a field other than the default
- Dependency changes
- Elixir ~> 1.2 is now required
- Ecto ~> 1.1 is now required
v0.13.1
- Enhancements
- If both an
:unauthorized_handlerand a:not_found_handlerare specified forload_and_authorize_resource, and the request meets the criteria for both, the:unauthorized_handlerwill be called first.
- If both an
- Bug Fixes
- If more than one handler are specified and the first handler halts the request, the second handler will be skipped.
v0.13.0
- Enhancements
- Canary can now be configured to call a user-defined function when a resource is not found. The function is specified and used in a similar manner to
:unauthorized_handler.
- Canary can now be configured to call a user-defined function when a resource is not found. The function is specified and used in a similar manner to
- Bug Fixes
- Disabled protocol consolidation in order for tests to work on Elixir 1.2
v0.12.2
- Deprecations
- Canary now looks for the current action in
conn.assigns.canary_actionrather thanconn.assigns.actionin order to avoid conflicts. Theactionkey is deprecated.
- Canary now looks for the current action in
v0.12.0
- Enhancements
- Canary can now be configured to call a user-defined function when authorization fails. Canary will pass the
Plug.Connfor the request to the given function. The handler should accept aPlug.Connas its only argument, and should return aPlug.Conn.- For example, to have Canary call
Helpers.handle_unauthorized/1:config :canary, unauthorized_handler: {Helpers, :handle_unauthorized} - You can also specify the
:unauthorized_handleron an individual basis by specifying the:unauthorized_handleroptin the plug call like so:plug :load_and_authorize_resource Post, unauthorized_handler: {Helpers, :handle_unauthorized}
- For example, to have Canary call
- Canary can now be configured to call a user-defined function when authorization fails. Canary will pass the
v0.11.0
- Enhancements
- Resources can now be loaded on
:newand:createactions, whenpersisted: trueis specified in the plug call. This allows parent resources to be loaded when a child is created. For example, if aPostresource has multipleCommentchildren, you may want to load the parentPostwhen creating a newComment. You can load the parentPostwith a separate
This will cause Canary to try to load the correspondingplug :load_and_authorize_resource, model: Post, id_name: "post_id", persisted: true, only: [:create]Postfrom the database when creating aCommentat the URL/posts/:post_id/comments
- Resources can now be loaded on
v0.10.0
Bug fix
- Correctly checks
conn.assignsfor pre-existing resource
- Correctly checks
Deprecations
- Canary now favours looking for the current action in
conn.assigns.canary_actionrather thanconn.assigns.actionin order to avoid conflicts. Theactionkey is deprecated
- Canary now favours looking for the current action in
Enhancements
- The name of the id in
conn.paramscan now be specified with theid_nameopt
- The name of the id in