You don’t want to disable CSRF, I have read that people think it doesn’t apply to JSON APIs for some reason, but this is a misunderstanding. To keep it enabled, you want to make a few changes: on there server side add a after_filter to your sessions controller: after_filter :set_csrf_header, only: [:new, :create] protected def … Read more
The confirm callback happens after create, so it’s happening on line 1 of your example, before you set confirmed_at manually. As per the comments, the most correct thing to do would be to use the method provided for this purpose, #skip_confirmation!. Setting confirmed_at manually will work, but it circumvents the provided API, which is something … Read more
Edit the user model and remove :registerable, I think that should give you what you want. Edit: I think this would work: if Rails.env.production? devise :database_authenticatable, :recoverable, :rememberable, :trackable, :validatable else devise :database_authenticatable, :recoverable, :rememberable, :trackable, :validatable, :registerable end
Remember to restart your rails server after installing and configuring devise.
Welcome aboard Java guy =), I hope you’ll enjoy the Rails world. Simply, to solve your issue you have 2 solutions: For each user create a table in the database and corresponding model. Create a single table in the database and for each user type create a model. This is called single table inheritance (STI). … Read more
This issue is due to a known string-corruption bug in Ruby 2.2.0 that was fixed in 2.2.2. As described in the bug report, the corruption occured when BCrypt called a specific string-creation API from its C extension, which Devise v3.3.0 triggered by calling ::BCrypt::Engine.hash_secret from the Devise::Models::DatabaseAuthenticatable#valid_password? method. A Devise-specific workaround for this bug was … Read more
I think this is a much better solution: if params[:user][:password].blank? && params[:user][:password_confirmation].blank? params[:user].delete(:password) params[:user].delete(:password_confirmation) end This prevents you from having to change the Devise controller by simply removing the password field from the form response if it is blank. Just be sure to use this before @user.attributes = params[:user] or whatever you use in your … Read more
token_authenticatable is vulnerable to timing attacks, which are very well explained in this blog post. These attacks were the reason token_authenticatable was removed from Devise 3.1. See the plataformatec blog post for more info. To have the most secure token authentication mechanism, the token: Must be sent via HTTPS. Must be random, of cryptographic strength. … Read more
at a glance answer. …instead of rails generate devise:views User use: rails generate devise:views If you’ve already done it, move the folders devise created from app/views/User to a new folder app/views/devise (or just rename the User folder to devise, if that’s an option.) Those folders are: app/views/User/confirmations app/views/User/mailer app/views/User/passwords app/views/User/registrations app/views/User/sessions app/views/User/shared app/views/User/unlocks No other … Read more
EDIT: In Rails 4 I now use what @genkilabs suggests in the comment below: protect_from_forgery with: :null_session, if: Proc.new { |c| c.request.format == ‘application/json’ } Which, instead of completely turning off the built in security, kills off any session that might exist when something hits the server without the CSRF token. skip_before_filter :verify_authenticity_token, :if => … Read more