spiffyjr / spiffy-authorize Goto Github PK

Hi,

I just want to share some thoughts about SpiffyAuthorize, which indeed looks very promising.

As I said to @spiffyjr on IRC, we now have three auth modules: ZfcRbac which is targetted to Rbac (and that is a little broken in some edges because iirc at the very beginning it was untetested, so a lot of features are still left not tested), BjyAuthorize for ACL, and this new SpiffyAuthorize that try to unify both.

As I suggested, I think it would be a good idea once this module is stabilized to deprecate ZfcRbac use. It's just going to be a whole mess if you, spiffy, don't maintain ZfcRbac anymore while you're still the owner and author.

On the other hand, I see some problems in this module and I'd like to have your feeling on this:

• The idea of unifying Rbac and ACL is quite appealing, but let's face it, nobody will change from one model to another.
• Nor you and I have any experience in ACL, so any abstractions you try to make both models work in SpiffyAuhtorize, we have no idea if those really work.
• As all ACL users are using BjyAuthorize, I think this module will receive few traction from ACL users, with the risk that the ACL layer is never implemented.

So that lead to my question: shouldn't we, instead, remove SpiffyAuthorize and move it to a refactor branch of ZfcRbac, and ONLY supporting RBAC, as before.

This would make architecture simpler, less maintenance and more contributions as people won't have the feeling that we "abandon" ZfcRbac, but instead made a new version.

What do you think?

Hi,

Currently (as it was the case in ZfcRbac), SpiffyAuthorize returns a 403 error when a user is not authorized.

Here is an idea for allowing a redirect strategy:

• Create a new UnauthorizedRedirectStrategy (and maybe rename the current strategy to Unauthorized403Strategy).
• Don't register any strategy by default, it's up to the user to register the strategy he wants.

The UnauthorizedRedirectStrategy would have the following options:

• redirect_route: the name of the route to redirect when a user is not authorized (most of the time it will be "login")
• append_redirect_to: can be either "true" or "false". If true, the previous URL route will be appended in the query param with the "redirectTo" param. For instance, if user try to access to http://www.mysite.com/secret, user will be redirect to the "redirect_route" with the previous route appended, for instance: http://www.mysite.com/login?redirectTo=http://www.mysite.com/secret

What do you think @spiffyjr ?