How can I blacklist usernames with Devise? - devise

I have Devise setup to allow login with email or username. With your username you can have a vanity URL like so: vanity.com/username. My User model thus has attr_accessible :username as well as attr_accessor :login.
To prevent usernames from colliding with future features, I want to implement a blacklist on certain usernames. You can see a nice example list in use by GitHub here.
I'm new to Devise and have searched the how-to's in their wiki to see if this use case or anything like it is covered there. It doesn't seem to be.
How can I blacklist certain usernames for registration in Devise?

There was an easier way to do this than having to modify Devise's controllers.
In the User model all I had to do was:
validates :username, :exclusion => %w(about blog ...)
Way too simple.

Related

omniauth-devise error: "Validation failed: Email has already been taken"

I am trying to create a rails 4 app with omniauth devise :
signin with facebook
signin with google
signin with linkedin
signin with twitter
Here, I am able to login in with either facebook, linkedin, twitter or google account. But my problem is: my google account email and linkedin email address are same. And login with google and then login with linkedin is giving me this error:
"Validation failed: Email has already been taken"
This is a problem because devise uses :unique => true in migration file for email field.
Can anyone provide me nice idea to handle this error please?
I think that basically, if handling all the cases properly, this can be really complex unless you choose option 1 below (and even then, there are issues to consider which I outline afterwards). Sorry for the length of this answer!
I'm assuming you've done something like this:
https://github.com/plataformatec/devise/wiki/OmniAuth:-Overview
so far, which gets you some of the way but doesn't handle the problem you're encountering.
The way I have done this, I have a User who has_many Identities. Identity stores the name of the external service, the user id it tells you and whatever else you want. This means that the same user can log in with multiple identities (twitter, Facebook…). Have you seen:
http://railscasts.com/episodes/235-omniauth-part-1?view=asciicast
http://railscasts.com/episodes/236-omniauth-part-2?view=asciicast
which help with getting going with the User has_many Identities, but still don't deal with your case.
Then to solve your issue, one option is to detect the validation error you're encountering:
if #user.errors.added?(:email, :taken)
# do whatever you want - e.g. one of the 4 options below.
end
and if it occurs, you could either:
just add the identity to identities associated with that existing user who has the same email address and then sign them in.
or
before adding the identity to the existing user, ask for the password for the existing user account (if the account was originally registered via devise on your system), so you'll need to go to some new controller/action and view that handles this flow.
or
Perhaps send an email confirmation (not devise's standard confirmation) to acknowledge that they are linking their new identity to an existing account. This sounds a bit complicated, because you'll have to store the identity temporarily somewhere (probably in a database if you want to cope with them ending their current session before clicking a confirmation link), flagging it as unconfirmed, until they click a confirmation link in an email (which you'll also have to deal with generating).
or
Perhaps force them to authenticate with the other identity that has the same email address. This has the advantage over the previous option that you can just save the new identity info in the session and get them to authenticate using the other service immediately, but obviously there will be some work to handle the flow there.
Option 1 can be less secure because you are trusting that external services have confirmed the user's email address - which perhaps they have - but you want to be sure otherwise someone could sign up with linkedin using their email address and then sign in to your site and then an attacker could sign up with another service but using the same email address. They could then access the person's account on your site if you didn't confirm they really owned the email address somehow (e.g. by using option 2, 3 or 4). If the external services can confirm they've verified the email addresses, then this option should be ok and is by far the simplest - for example, Facebook have a field that tells you the account has been verified (but see my comments below about services that don't need email addresses). If they're merging with an account registered with you directly (doesn't sound like your situation), you should have confirmed the email address they registered using devise's standard Confirmable feature.
Option 2 sounds like it doesn't apply in your case, because you don't mention that a user can register with you directly via devise; only sign in using external services. This means that they have no password on your site that they know. (You've probably added a dummy one to get the devise validation to pass, unless you've disabled that, but they won't know the password unless you've told them somehow, and it could be confusing to them to do that).
Option 3 sounds do-able, though I haven't tried it. It's a bit more laborious for the user.
Option 4 also sounds do-able, though I haven't tried it either.
So far, I've done option 2 because users can only register with my site either directly using devise or via 1 external service. I'll be adding other services soon, so I plan to use option 4 (perhaps only if external service says they haven't confirmed the email address, and option 1 otherwise).
Options 2, 3 and 4 are a fair bit more work than option 1, so it depends if you can confirm that the external services have verified the email addresses and if not, how paranoid you are about attackers being able to access user accounts on your site. Personally, I err on the side of paranoia!
This might also give you some more useful info:
https://github.com/intridea/omniauth/wiki/Managing-Multiple-Providers
but because omniauth itself doesn't concern itself with model issues, it mostly sidesteps it, though it says for your case that it is "probably sufficiently prudent to assume that they are, in fact, the same person who also created the previous user" but you have to be able to trust the external services as I mentioned above.
There are also other things to consider, such as the case where someone has the same email address registered with Facebook and linked in and has signed in with both on your site (so single user account once you've dealt with your issue) and then changes the email associated with their Facebook account but not linkedin. If you always overwrite the email stored in the user table with the one from the external service, then it'll keep changing if they log in with linkedin and then Facebook (but maybe this doesn't matter to you). Alternatively, they may have different email addresses registered with Facebook and linked in and have logged in with both on your site (so 2 different users on your site) and then they change their linked in email address to be the same as the Facebook one. If you update the email address for a user every time they log in via an external service, you'll have your "Email already taken" error, but in this case you have 2 existing users to merge which could be interesting depending on what else in your database is associated with a user...
Also, I don't think twitter returns an email address, so if the same person has logged in with twitter and linkedin, you won't detect this. Furthermore, I think email is optional with Facebook (you can use a mobile phone number), so the same thing can happen with Facebook. My ideal solution would allow the user to merge arbitrary accounts, obviously having to enter whatever credentials are required to confirm they own the accounts they are merging! I haven't done this yet, but it's on my wish list!
I followed these steps and working fine for me:
1. Gemfile
gem 'omniauth-facebook', '1.4.0'
gem 'omniauth-twitter'
gem 'omniauth-google-oauth2'
2. config/route.rb
devise_for :users, controllers: { omniauth_callbacks: "omniauth_callbacks" }
3. Links
<%= link_to "Sign in with Facebook", user_omniauth_authorize_path(:facebook) %>
<%= link_to "Sign in with twitter", user_omniauth_authorize_path(:twitter) %>
<%= link_to "Sign in with google", user_omniauth_authorize_path(:google_oauth2) %>
4. controllers/omniauth_callbacks_controller.rb
class OmniauthCallbacksController < Devise::OmniauthCallbacksController
skip_before_filter :authenticate_user!
def all
user = User.from_omniauth(request.env["omniauth.auth"], current_user)
if user.persisted?
flash[:notice] = "you are successfully logged in!!"
sign_in_and_redirect(user)
else
session["devise.user_attributes"] = user.attributes
redirect_to new_user_registration_url
end
end
def failure
super
end
alias_method :facebook, :all
alias_method :twitter, :all
alias_method :google_oauth2, :all
end
5. add required fields and model
rails g migration add_social_network_info_columns_to_users name image_url locations
# generate new model Authorization
rails g model Authorization user_id:integer provider uid token secret username
6. models/User.rb
class User < ActiveRecord::Base
require 'securerandom'
# Include default devise modules. Others available are:
# :confirmable, :lockable, :timeoutable and :omniauthable
devise :database_authenticatable, :registerable,
:recoverable, :rememberable, :trackable, :validatable,
:omniauthable
has_many :authorizations
# omniauth facebook provider
def self.from_omniauth(auth, current_user)
# check for existing authorization
# Find or create Authorization with: provider, uid, token and secret
authorization = Authorization.where(
:provider => auth.provider,
:uid => auth.uid.to_s,
:token => auth.credentials.token,
:secret => auth.credentials.secret
).first_or_initialize
if authorization.user.blank?
user = current_user.nil? ? User.where('email = ?', auth["info"]["email"]).first : current_user
# save user related data in user table
if user.blank?
User.new(
:email => auth.info.email,
:password => Devise.friendly_token[0,10],
:name => auth.info.name,
:locations => auth.info.location,
:image_url => auth.info.image
)
# since twitter don't provide email,
# so you need to skip validation for twitter.
auth.provider == "twitter" ? user.save!(:validate => false) : user.save!
end
# store authorization related data in authorization table
authorization.username = auth.info.nickname
authorization.user_id = user.id
authorization.save!
end
authorization.user
end
end
6. model/Authorization.rb
class Authorization < ActiveRecord::Base
belongs_to :user
end
source:
https://github.com/mohitjain/social-login-in-rails

Require username at registration

Ive been searching and cant seem to find a question that answers this. Im pretty new to devise. Ive added a username column to my users model, and added the username field to the registration form.
But how can I require that the username field be filled out upon registration? Also check thats its unique?
If you want the login to be by username (and not the devise-default email), Ryan Bates has you covered in his RailsCasts episode # 210 : Customizing Devise See the last section on Customizing the Login Requirements.
If however, username is an additional field in the User table, add it as attr_accessible and write normal rails validations. Example:
validates :username, :presence => true, :uniqueness => true
It might require some customization of the views as well to standarize the validation errors display.

rails access signed in user and the user id for the profile for a multi-page profile

Hi clever programmers,
I've been searching and reading a couple days, but I need some Rails help-
Here is my goal: I want to make a multi-page profile for each user, and I'd like to handle this profile with a profile controller.
The problem? How do I make the 'show' REST action apply to an entire controller instead of just one page? Specifically, how can I have both a #current_user and a #user variable available in the Profile controller that correspond to the signed-in user and the current user's page.
I'm not sure if I should be making routes with multiple :id s in the route or if there is some way to persist the signed-in-user in something like #current_user when they sign in that is just available everywhere and then I would use the :id of the user who's profile it is in the route. I'm pretty sure facebook does something like facebook.com/{your_id}/{their_id}/ for example.
I tried accessing #current_user from my session_helper.rb class but it came up nil and I'm not sure how to pass the :id to use User.find(params[:id]) because the profile controller is not affiliated with the resource for the User model.
Any protips or links to helpful readings would be much appreciated. I'm a beginner so feel free to suggest a better course of action if I'm going against the rails way. Thanks in advance!
You may not know but you can store session data, and user_id it's really common thing that people saves on it.
So for saving at the sign in
session[user_id] = ....
Then you could have something like this on a helper
def current_user
User.find(session[user_id]) if session[user_id]
end
You should check the gem called devise. It provides all the functionality for aunthentication and it also provides a current_user method everywhere. You should check it at least to see how they have implemented that method.

Best way to model users that have roles with differing attributes in Rails?

I'm a Rails noob and am hoping someone can help me wrap my head around this issue. I have an app that has a single User model using Authlogic for authentication and CanCan for authorization. There are three roles: Consumer, Business, and Admin. A user can have any number of these roles.
Businesses have additional attributes, however, and I need to model this such that I can add roles that each have potentially different attributes. Instinct tells me that I need to have a separate model to represent each role's attributes, i.e. BusinessRoleProfile, ConsumerRoleProfile, etc and then maybe mixin a module programmatically that adds the appropriate has_one reference(s) to the profile model(s).
Is this the best way to handle the separate attributes? If so, can someone guide me through how to dynamically include those mixins based on what role the user has?
EDIT:
Did some more research, this may help you. https://github.com/thefrontiergroup/scoped_attr_accessible
Looks like you can do things like:
class User < ActiveRecord::Base
# All attributes are accessible for the admin scope.
attr_accessible :all, :scope => :admin
# The default scope can only access a and b.
attr_accessible :a, :b
# Make both :c and :d accessible for owners and the default scope
attr_accessible :c, :d, :scope => [:owner, :default]
# Also, it works the same with attr_protected!
attr_protected :n, :scope => :default
end
OLD ANSWER
Looks like it may be featured in CanCan 2.0.
https://github.com/ryanb/cancan/issues/326

Using Devise with a singular Resource

I'm a newb with Rails and am trying to get out my first Rails 3 app with Devise. I have a situation where pretty much everything on my site is specific to a user. I'm creating a kind of private gallery that isn't public facing, so that every image belongs_to a user and a user has_many images. Here's my issue... I want to rework my routes so that showing a users images doesn't require a user id in the URL. I will be showing a user's images in the user/show route.
current route (from rake:routes):
/users/show(.:format) {:action=>"show", :controller=>"users"}
Is it possible to have devise use only "resource" instead of "resources"? so it would be /users/show/? Am I making sense? I am not sure the terminology to ask, but I want all of a user's functionality to imply that I know who the user is, then I can check that in the controllers.
Thanks!
In your controller, for the show action:
def show
#user = current_user
end
That's all you need to do. If you were EXPECTING an id, then you do something like #user = User.find(params[:id], but since you know what user you want (in this case, the current_user, which is exposed by Devise), you don't need to do anything special.