Does rails impose any automatic rules for password fields? - ruby-on-rails-3

Background:
User record creation in the application I'm working on is failing with errors "Password is too short (minimum is 4 characters)" and "Password confirmation is too short (minimum is 4 characters)".
Neither the User model nor any of its included models mentions passwords. The only places in the application where I can find them mentioned is in forms within the views and in the original database migrations. There is a crypted_password column, and a password_salt column in our users table. We are NOT using devise. The only security_related gems in our gemfile are attr_encrypted and encryptor, neither of which seem to mention any special treatment of passwords in their documentation.
So, since length validations and encryption are in fact happening, and I can't seem to track it down to a model or a gem, where might these rules be coming from? Is there a way I can disable them?

It turns out our application also makes use of the AuthLogic gem, which adds its own validations on login and password by default. As per this page of the documentation, the validations can be overridden in an application-wide configuration or in per-model configuration blocks.

Related

What to use for user registration when creating a Rails 5 API-Only app?

There are plenty of articles and resources out there about different options for authenticating and accessing a user's information via a Rails 5 API, such as Knock, Doorkeeper, JWT, etc, but I am having trouble finding a solid recommendation on how to handle the actual registration of a new user and related features (i.e. password requests).
I could use Devise, but I wonder if it's overkill. In fact, many articles dealing with JWT, as well as gems like Knock, recommend against it.
Is there a different recommended solution for handling new user registration when building a Rails 5 API only application or is Devise still the best way to go here, even with all the other overhead? Does Rails 5 have something built in?
I`m in the same situation like you I wanted to build a rails 5 api and use JWT but a all the articles omits the register part :S I though like you on use Devise but we only need the register part we wouldn't need the authentication and other modules that are on devise, so the solution would be add register functionality from scratch or if you don't want to code something from scratch then you can use devise but modified to work along with token authentication see this wiki post

Devise support for multiple concurrent sessions

I'm using Rails 3.2.11 with Devise 2.2.3 for a subscription service application. I inherited the app from another developer who is no longer available. I am new to Rails and Devise.
I want to allow a single user (email) to have more than one session to the same app, running concurrently. The sessions may all have the same IP address or different IP addresses, though probably different devices -- desktop, laptop, table, smart phone.
I want to treat each session independently, so the user can sign on and off one session without affecting any work in progress on another session.
Question: Does devise support multiple concurrent sessions normally? Do I have to customize any code or config?
When I look at the User model, I see single attributes for "current_sign_in_at", "current_sign_in_ip" and "authentication_token" -- this makes me think a single User can only have one session at a time.
I've looked at this discussion and at the devise wiki but haven't found an answer.
Yes, devise allows multiple concurrent sessions for same users by default. Then, if you want restrict this behavior, you need to use some extension like: devise_security_extension
I'm using Rails 3.2.17 with Devise 3.2.2

Non-login users for devise

I'm using devise on Rails 4.0. I need non-login users, that is, people who are considered part of a team but never need to log in or interact with the app, they just get emails, appear in different lists and so on (in the future, however, they can potentially become users).
Ways I'm guessing how to do it are to:
programmatically add them, then -
possibly generate the devise views so I can alter them for non-login users?
write the controller to block non-login users?
I need to know what would be the basic steps for implementing non-login users.

Rails Devise broke on sqlite -> Mysql upgrade

I have a rails 3.0.9 application that is using Devise for user authentication. It was previously using SQLite, but I changed my application's database to MySQL.
Upon switching to MySQL, the user registration function of Devise stopped working. I'm not getting an error in the rails log. When a new user tries to register, they are simply routed back to the signup page after clicking 'Submit.'
Are there any DB references in the Devise config files that I need to change in order to having Devise play nicely with MySQL?
I should also not that user login / logout is working correctly under MySQL.
I just realized that I had added a before_save :default_values filter on my user model. I originally did this to set default values for certain attributes on the model level. I instead ran a migration setting defaults at the DB level, deleted the before_save call from the model, and everything worked fine.
Silly mistake. Hopefully this helps someone else.

Storing users and admin users together in mongodb

I'm writing a ruby on rails application using mongoid and I'm wondering about the security implications of storing users and admin users in the same document. My current implementation is using devise and kind of modeled on how activeadmin does it. The admin users are in a separate document so there isn't any chance of someone escalating their privileges. This is a public facing site and there is some financial information involved.
But i'm curious if maybe I'm just making more work for myself and this is kind of unneeded.
There shouldn't be any implications as long as you prevent users from being able to update the mechanism for privileges. If you have a boolean flag called is_admin for example, ensuring that you have attr_protected :is_admin is vital to protect against mass-updated from changing this privilege.