Permissions ensure users can access the features they need, and are denied access to features they shouldn’t be using. They keep systems safe from any malicious or accidental actions such as data loss, or leakage to people who shouldn’t have access. Lucky for us, Solidus provides a robust, flexible system for permission management that can support the many different setups stores might require.

Permissions are important

It is important for permissions to be easy to use and manage. If they are too difficult, administrators will not require them and users will not use them, which can lead to security vulnerabilities. This is a huge liability, which we saw with Equifax in the Fall of 2017. They gave users overly broad permissions that allowed them to access information more sensitive than they needed, which exacerbated the data leak. It is common practice to use the principle of least privilege when deciding on permissions for anyone in a system. This means providing only the minimum required permissions to users. This ensures regular function without disruptions to users while keeping the system safe.

Stock Solidus Permissions

Out of the box, Solidus uses the authorization framework CanCanCan for managing roles of both individual and grouped resources. If you are familiar with CanCanCan, you might find the Solidus permission system unfamiliar, because Solidus abstracts away CanCanCan’s idea of “abilities” with its own concepts:

1. Roles determine which permission sets are in charge of a user’s access to resources. Users can have multiple roles, and each role can have multiple permission sets.
2. Permission sets contain logic that defines what a user can do with a resource.
3. Role configuration associates roles with permission sets.

For example, many stores have a dedicated customer support team. They need to access and modify orders and users, but don’t need to modify products or site configuration. In this case they might have two permission sets: one for managing orders and one for managing users. This ensures that the customer support team won’t be able to accidentally change a payment method or shipping method, while still being able to view information that is crucial for customer assistance.

This could be made into a single permission set, however breaking them apart means we can also reuse them for other roles. For examplex someone working in human resources might need access to manage which roles belong to which users. We can easily support this by giving them the user management permission set. Since they don’t need access to orders, we can omit the order management permission set.

This is how you could set up those two permission sets.

module Spree
  module PermissionSets
    class UserManagement < PermissionSets::Base
      def activate!
        can :manage, Spree::User
      end
    end

    class OrderDisplay < PermissionSets::Base
      def activate!
        can :read, Spree::Order
      end
    end
  end
end

This is how you would define separate configurations for the customer support and human resources roles:

Spree::RoleConfiguration.configure do |config|
  config.assign_permissions :customer_support, [
    Spree::PermissionsSets::UserManagement,
	Spree::PermissionsSets::OrderDisplay
  ]
end
Spree::RoleConfiguration.configure do |config|
  config.assign_permissions :human_resources, [
	Spree::PermissionsSets::UserManagement
  ]
end

A stock Solidus store contains two roles: default and admin. If a user is not authenticated, they get the default role. It’s important to consider what roles you need when you first set up your store, but you can always add or change roles later. For a starting off point, check out Solidus’ predefined permission sets.

Solidus’ view temlates are full of permission checks that you can use as a reference when implementing your own. Here is an example from the admin:

<%= form_for [:admin, @store] do |f| %>
  <%= render 'form', f: f %>

  <% if can? :create, @store %>
    <%= render 'spree/admin/shared/new_resource_links' %>
  <% end %>
<% end %>

This can be found at backend/app/views/spree/admin/stores/new.html.erb. This view renders a form for creating new stores. The can? check that is ensuring the current user is allowed to create a new store, before it renders the create button on the page. It’s really as simple as that.

Your permission system is meant to grow with your store and organization. It’s smart to keep in mind that starting with small permission sets can set you up for success in the future. It’s much easier to add permissions than it is to take them away, so it’s a good idea to start with the smallest amount of permissions you think you need and then add more from there.