Remove CanCan dependency

[hazah]

I can see that it's the default implementation for the guards, but I think this should be more generic. Perhaps a strategy adaptor for forwarding the method calls? This way you're not tied to a particular authorization solution, simply relying on one being provided.

Further to that, if no authorization is available, you can default to an always allow state.

[coffeeaddict]

Other than that I do not like "always allow" approach (some pain is good) I do think that using an adapter/wrapper for the guard is pretty clever.

Looking forward to your pull requests 😉

[hazah]

It'll be a while. I've been refactoring your code but its taken on a new direction for me. Attempting to embed an actual service layer into rails with initialization hooks. In my scheme the guard becomes a separate service, but I'm not quite there yet.

I'll cook something up that's far less drastic in another fork.

[hazah]

Basis for my thinking is pretty simple. What does it mean to "allow" or "deny"? Strictly speaking, the meaning only makes sense if you have a context. Right there is my dilemma: "context" can be set up by a service.. and I don't see a reason that it should not be. I'm still hashing out the details, but am curious.. what are your thoughts regarding the approach?