For secure authentication, our web app uses the Devise (4.0) ruby gem which is the industry standard for authenticating Ruby on Rails applications. The security benefits of Devise lie in its DatabaseAuthenticatable module, which handles the hashing of the password and authenticating users upon sign in. The Devise module uses BCrypt and its own Encryptor module to accomplish secure password encryption.

devise/lib/devise/encryptor.rb

The ::digest class method concatenates a random string (pepper) to the password before the password is hashed. This decreases the chance that a malicious user could hack the password based on the hash function.

Security Updates: A second benefit to using the Devise gem is consistent security updates. While there are drawbacks to using a gem like Devise in one’s app, such as time spent learning & dealing with its intricacies and customization - the tradeoff is that the engineer doesn’t have to envision every potential malicious attack on their hand-rolled authentication (like session-fixation attacks, for example). New versions of Devise will often add more security than before because as vulnerabilities are discovered (whether due to real-world cyber attacks or community feedback), patches are made. This will require the app to be updated as the Devise gem updates, but as a result will improve the app’s security.

Devise Modularity: Devise is based on the modularity concept - use only what you need, and customize as necessary later. As the GeniePortal develops and more auth customization may become required, doing so is a matter of the engineer adding in optionable modules and customizing controllers as needed. More information can be found in the Devise docs.

Devise Controllers: Inside the sessions folder & users folder contains our Devise-generated controllers. In our registrations_controller is where we set the strong params for values used in signing up (in addition to email and password) and updating our account, respectively. These methods are called configure_signup_params (bylaw_agreement) and configure_account_update_params (email, password, username, first_name, last_name). RegistrationsController#new, #create, and #destroy are also uncommented and the ‘super’ call made to allow for these methods to be accessed based on the Devise inheritance. In the sessions_controller our #create method overrides the Devise controller, while still relying on its methods and security. This was done to allow for a successful session creation to render to the JSON show page instead of the Rails view, which Devise renders by default. genie-portal/app/controllers/sessions/sessions_controller.rb

CanCan Authorization Authorization for managing which pages users can and cannot access is done via the CanCan authorization library. CanCan provides a simple but powerful model that can set / limit admin abilities across models. The ability.rb model is where this happens. Instead of setting authorizations for every different model, simply set the method load_and_authorize_resource in the controller where you want that model to be authorized for every action in that controller. You can pass to the abilities to initiate CRUD methods like :read, :create, :update, :destroy or simply pass :manage for the user to be able to complete all actions.

Using JSON / React with Devise: Controllers were updated to ensure that JSON formatted requests would not cause a CSRF (Cross Site Request Forgery) error, as Rails normally passes a hidden authenticity token to the browser in every GET / POST request made. This protect_from_forgery method method normally auto-generates a security token in any form / AJAX request that Rails generates. With the changes made above, the request is still protected by an empty session, using :null_session . More information is available here on request forgery protection when using JSON. genie-portal/app/controllers/application_controller.rb