Authentication doesn't belong in your Rails Engine | Hacker News Reader

Authentication doesn't belong in your Rails Engine

ryanbigg.com

28 pointsforkhammer5 comments

As someone who has worked on all three projects — Forem, Spree, and Refinery — it's a pain in the butt trying to get them to work together. Forem's approach is brilliant, but it's also a user-friendliness issue to require them to provide their own authentication.

I agree with what the author has to say, largely, but I think there needs to be a way to provide a sane default.

Sorry for copy-pastaing my reddit comment on this same article, but I think it's relevant to your point.

--- I feel very strongly about this, and I agree entirely. I think projects should go one step further. For something like forem, I think it makes sense to have a gem called forem_auth, and for the installer to give you an option to install the engine as a standalone app. If you choose to, it would include the forem_auth gem in the Gemfile, and you'd get auth built in. Otherwise, you configure it for your own auth.

I think refinery and spree should adopt identical stances to forem in this regard. I also plan to take this a bit further in all of my engines going forward, and defer the persistence decision entirely, making it trivial to switch out ActiveRecord or mongoid or csv files or whatever. Experimenting with this on internal apps presently, and it shows comically awesome amounts of promise.

I think it's a relatively normal thing for lispers to defer decisions like that until they no longer have to decide - that's what we've been doing. ---

I've been thinking about rails engine interoperability for quite a while, as have the spree/refinery/other forem guys, and I've got a very solid mental model of what it needs to be to make plug-and-play a possibility with these style components. It is definitely within reach, and we need some other people to get on board with these ideas to make it the obvious choice for future engine makers.

What ever happened to convention over configuration? Why are "engine" developers even making this decision?

Convention over configuration was always easier in smaller decisions where people didn't have very strong opinions. i.e., "model files go in ./app/models/" When it comes to more subjective, more context-dependent decisions like authentication libraries, the general drift has (wisely, I think) been to build hooks into the core and let non-Rails-core developers have a healthy competition about which libraries are best.

Of course, this means the Rails user base is getting slowly more fragmented as more options become viable, but generally speaking this is a good problem to have.

To make it "easier" for people to use their engine. Obviously this is wrong.

Reply on news.ycombinator.com