I'd like to implement a third-party Ruby on Rails authentication system that is actively developed and carries sensible defaults.
I've narrowed down my selection to AuthLogic and Clearance (thoughtbot) -- can anyone sway me in either direction? In terms of requirements, both would work for my project from what I can tell. It looks like documentation/code samples in both are fairly similar, and both are relatively easy to setup.
Anyone have a preference? I really like AuthLogic's OpenID plugin -- don't know if Clearance can do that.
Devise for sure :)
https://github.com/plataformatec/devise
I have used the restful_authentication gem, authLogic and Devise and I like devise 'cos it's model based (higher up the stack is better and easier to rspec) and also lets you just put in an admin flag in the user table for admins and go with that (or use roles for more complex stuff).
Another gem that has become common with devise is cancan for roles, e.g. admin, reader, manager, etc (whatever you want) with syntax like below (from the cancan gem).
<% if can? :update, #article %>
<%= link_to "Edit", edit_article_path(#article) %>
<% end %>
Did you already rule out Devise for some reason?
If not, it's the most current and complete authentication framework for Rails. As for openID authentication, take a look at OmniAuth, which integrates seamlessly with devise.
Questions about authorization are often poorly formulated because we are all interested in different aspects.
In my case, we have a well developed application (Wagn, see http://wagn.org), and it has a home grown authentication functions built in already. What we are doing is making the application independent of the authentication system, so I am most interested in two dimensions:
1) What is the API for the provider interface and how easy is it to add to my app.
I've just done a lot of work to route all of it through a set of class or module methods that the application uses, and a model for the home grown AR class (a User class and users table) that. This leads to the next part:
2) What authorization providers are available and what do I have to do to load them with my application (typically I would expect these to be in one or more Rack middlewares).
I don't need Devise, it does too much, I want an interface to external auth providers. My app may provide forms that will post parameters to the auth services, but it won't be using their Rails views or controller.
I suspect this situation is common for a certain class of developers.
Related
I have an existing rails app with Mongo DB.Currently the app can be accessed by anyone that is every method in Portfolio controller and customer controller. Now I want that Portfolio controller should only be accessed by sign in user. How can I do that. I tried using active_admin but was unsuccessful.
You're looking for User Authentication. Try any authentication plugin like Devise or Clearance to sign in and distinguish individual users (more options here) or, even better at first, try building your own authentication solution alongside some of these excellent RailsCasts on User authentication (the paid episodes are totally worth it!). You'll learn how the different moving parts fit together real quick.
You might also want to consider using the Sorcery (https://github.com/NoamB/sorcery) gem as another option. It has links to the railscasts on the github repo there which helped a lot, and myself as a beginner found the wiki to be incredibly in-depth. Super easy to use.
I'm learning Rails 4 and I'm looking to build in some basic admin functionality such as creating and viewing users. I can think of a few ways to do it manually, (such as creating a new controller or adding filters) but I'm pretty sure there's a "Rails Way" to do this easily. I've been digging through the docs and I see references to "built in authentication" that support my hunch, but I can't find the actual documentation.
For example, in CakePHP you can just prefix actions with admin_ and /admin/controller/action will work automatically. Is there a similar convention for Rails? If so, where can I find it?
Update:
As I continue to research this, I start to get the impression that admin authorization in Rails is commonly not handled by the Rails core, but rather in a gem like cancan. Perhaps this is why I was striking out by searching the Rails docs.
Update2:
This question wasn't intended to be a round-up of authorization gems, but since it appears gems are the typical way to handle even basic admin authorization, I'd like to find the simplest, most basic (and hopefully universal) option. A couple options have been proposed below which come bundled with default dashboard views and elaborate configurations. I don't need all that. Just a simple, reliable strategy for dividing users into admins and non-admins with different scopes of allowed actions.
Check out the awesome rails_admin gem. It automatically generates just about everything you could need. Very handy and awesome project. https://github.com/sferik/rails_admin
Authentication is handled via the devise gem and authorization via cancan.
It's no replacement for custom admin functionality if you have very specific requirements, but it's great for general admin tasks you described.
I am about to build a new site in ruby on rails for residents at my college.
The site will allow residents to change their passwords for the college-firewalls (which means there are certain requirements).
On the site, each resident will have an account with a number of data assigned to it, and for this I need some authentication.
I've been studying Devise for almost the entire day now, but im starting to wonder if I have a too complicated task, to complete it with Devise.
Problem is, I need the passwords to be stored with DES-encryption, something Im not sure if Devise can handle.
Another thing is, users can't make their own profile. Admins will do that (to ensure correct data), which means that user-creation is not the default one. Since there are no controllers for this, is it even possible to do it that way?
I'm not sure if I should keep on going with Devise, or bite the bullet and write it all from scratch instead. Some opinions would be appreciated.
This page on the Devise wiki ( https://github.com/plataformatec/devise/wiki/How-To:-Create-a-custom-encryptor ) tells you how to set up a custom encryptor.
To make it so that admins create a user, remove the :registerable module from the User model. Then add a user resource to your app, example:
scope 'admin' do
resources :users
end
Set up the new/edit pages with your profile fields, etc., normal rails programming.
For an example using CanCan to control access to the users resource, have a look at this post: http://zyphmartin.com/blog/manage-users-with-devise-and-cancan.
If devise does not exactly do what you need, maybe this recent webcast from Ryan Bates will help you.
I am building a project management app and I am not sure which is the best/correct authorization model to implement given I am new to Rails (and programming in general). Here is what I am trying to do.
I want to be able to add a "client" to the application and then multiple projects to a client. I would like to be able to add users (that are essentially representatives of the client) to view that clients multiple projects but not other clients. I intend on having controllers for time tracking, notes, comments and images all to be associated with both clients and project of that client.
In addition, I would like to set up the account to control who is able to have one. I don't need the user to establish an account on their own.
Does that make sense?
I believe what you are mentioning is called Authorization not Authentication, anyway:
I would suggest acl9 for authorization and authlogic for authentication.
These (free) Railscasts should give you some food for thought. There are lots of great RubyGems/plugins out there for this sort of thing.
The Ruby Toolbox gives you an overview of tools and their popularity in the rails community (rated by watchers and forkers on GitHub). As you can see there, the suggested plugins restful_authentication and authlogic are almost on the same level.
Restful Authentication is still the golden standard for user authentication in ruby on rails.
I have used Authorization plug-in in the past and like it because it gives some nice meta methods such as:
user.is_eligible_for_what --> returns array of authorizable objects for which user has role "eligible"
user.is_moderator_of? group --> returns true/false
user.is_moderator_of group --> sets user to have role "moderator" for object group.
user.is_administrator --> sets user to have role "administrator" not really tied to any object.
There's also a brand new RailsCast on CanCan.
I'd use AuthLogic for authentication (logging in users and making sure they are who they claim to be) and declarative_authorization for authorization (making sure they have access to resources). See Ryan Bates' excellent Railscasts on AuthLogic and restful_authentication for more info.
I am having a hard time getting my head around the responsibilities and capabilities of the popular Doorkeeper and Devise gems. I am not overly experienced in authorization and authentication so pardon me if I misunderstood certain aspects of those areas. I do try hard and if I do something I want to do it the right way, so here is my current situation:
I want to build an API-only rails application that is responsible for authenticating and authorizing users as they sign up and use the service. I handpicked two fairly popular gems called Doorkeeper (authorization) and Devise (authentication).
I currently have this structure in place and it works, however, I'm having issues fully getting behind what the responsibilities of these gems are. So as far as I understand, the Devise gem serves as an authentication layer, meaning that the user can be identified and logged in (additional features will be discussed below). Doorkeeper on the other hand will ensure that resources can only be accessed by members who are authorized to do so. I have chosen Doorkeeper for OAuth2 integration because my server needs to be able to give access to the API to potential third parties in the future.
My question first and foremost is whether my assumptions about those gems is correct.
Here is the current authentication/authorization flow:
Issue: User signs up, how do I leverage Devise to send a confirmation email if my API is devoid of the preconfigured views provided by Devise? (Side Note: The traits Recoverable, Rememberable, Trackable, and Confirmable are in the User model/migration.)
Similarly, I would love to know how to implement a potential password reset. Notice that references to examples would suffice too as long as they are applicable to my use case.
I know that Devise offers these capabilities, but it's hard to make out how to do it without hitting their preconfigured (view?) routes.
For example, when a user signs up, he hits my own user_controller's create method, which basically just creates a new user, is that supposed to automatically send a confirmation email (if we assume that my mail config is correct)?
I am not entirely sure whether avoiding the preconfigured routes makes a lot of sense, that's why I'd like to hear from more experienced people who may have used those gems in the past if my thinking is correct or whether I'm completely off on this.
I've done exactly what you're looking for and I really think this is a good choice. I've never regret it. What you're actually trying to do is to have the exact same behaviour that native Devise implementation but on an Engine via API. Plus, you want to apply it to a Doorkeeper authorisation.
Short answer is: override default views/controller/routes.
Why should I override views?
You're using Rails API means response will be JSON but you're using a certain standard to wrap it and Devise might not be the same. For example, if you want to respect OpenAPI standards, it's not possible natively (please correct me if I'm wrong).
This leads to an override of the controller as well to be 100% sur of what you're returning. I would also add an extra layer here about versioning. Now you're plans might be fixed but you don't know about tomorrow.
Overriding controller leads to an override of the routes itselves.
Wait, how am I suppose to do that?
On your global Gemfile.rb
# Gemfile.rb
gem 'devise'
Nothing changes for devise initializers if it's on an engine or not
Keep config/initializers/devise.rb as usual
Routes are now defined on your engine:
# your_engine/config/routes.rb
YourEngine::Engine.routes.draw do
namespace :v1, format: false, defaults: { format: :json } do
devise_for :users, controllers: { sessions: 'your_engine/v1/users/sessions',
registrations: 'your_engine/v1/users/registrations',
confirmations: 'your_engine/v1/users/confirmations',
unlocks: 'your_engine/v1/users/unlocks',
omniauth_callbacks: 'your_engine/v1/users/omniauth_callbacks',
passwords: 'your_engine/v1/users/passwords' },
skip: %i[sessions]
end
end
I've deliberately skipped sessions since we're talking about API and there is no such things (for now).
Add Devise to Doorkeeper using resource owner password credentials:
Doorkeeper.configure do
base_controller 'ActionController::API'
api_only
resource_owner_from_credentials do |routes|
user = User.find_for_database_authentication(:email => params[:email])
if user && (user.valid_for_authentication? { user.valid_password?(params[:password]) })
user
end
end
end
All your controllers must inherit from Device controllers. I inspired myself from it to made my overrides.
This way, you can have your API entrypoint for Devise but you can also have another one with a non-api access building another Engine. It's the same process but requirements come from a different order that for the API (views -> controllers -> routes). For Devise on an engine, I would say order of comprehension is routes -> controllers -> views.
I hope this helps you. Good luck! 😉
Devise is really made to do everything for you, if you bypass the automatic mecanisms and want to re-implement them by hand... you WILL make a mistake.
Don't bypass controllers mecanism and use the devise's wiki for small customizations like changing the redirection after creation/update.
Devise handles confirmation emails (confirmable) and password reset (recoverable) system for you so use their system, it is just options to activate.
If you wanna change their view (we always want to customize the layout) you can :
rails g devise:views
It will keep the devise flow, with your custom views.
If you wanna stop using a specific mecanism, just remove it from the model.
devise :database_authenticatable, :registerable, :confirmable, :recoverable
Avoid preconfigured routes would have made sense if did not used them at all (meaning removing the option and using except in routes), but as you want all the mecanisms Devise provides it does not make sense here.
Their Wiki is really dense but read it again and again, everything you need is here.
Finally :
Yes Gatekeeper provides a good OAuth2 provider system and mixes up very well with Devise, so you made a good choice here. Their views system is also customizable.
You might also want to take a look at cancancan that handle roles and rights for your users (simple, API, admin, etc).
Hope it helps !