grounded / afterburner

A bunch of ideas allowing developers to defer decisions in, and reduce coupling of, an application's technology stack through the provision of design patterns.
MIT License
4 stars 0 forks source link

Authentication should not be built in #8

Open GeekOnCoffee opened 12 years ago

GeekOnCoffee commented 12 years ago

Summary from Spree's recent move to this:

Spree no longer ships with authentication included. Previous version of Spree have relied on a third pary library known as Devise. By removing the dependency on Devise this allows Spree to be more easily integrated with larger Rails applications that may have their own authentication system. For those that are using Devise (or have no strong preference for which system they use), we still have Devise support for Spree. You’ll just need to add the spree_auth_devise extension to your application.

http://guides.spreecommerce.com/authentication.html has information on how it's pulled off

knewter commented 12 years ago

+1, imo the biggest remaining hurdle to an uptick in a "Rails Engine Ecosystem" that is only just now maturing (a bit late)

radar commented 11 years ago

I like the idea of setting a class variable. It's worked well within Spree and Forem. With that value, then you constantize it and then assume that class follows a certain API. How we ensure that API is present, I don't know yet.

knewter commented 11 years ago

So we can define the API solidly, and then if your default user/auth doesn't implement it you can be responsible for implementing a wrapper that does.

parndt commented 11 years ago

So we can define the API solidly, and then if your default user/auth doesn't implement it you can be responsible for implementing a wrapper that does.

That's a bingo!

johanb commented 11 years ago

:+1: