Clone this wiki locally
BrowserCMS has a built in Authentication system that is similar in functionality to projects like Restful_Authentication. It models Users and Groups, where each User can be part of many groups, and each group can have multiple permissions. It also handles the modeling of whether users can view or edit specific sections (and the pages within).
How it currently works
Each controller within the CMS that needs security will include the following module.
This adds several important methods and filters to the controller, including:
login_required– (Filter) Asserts that the user must be logged in to access this controller.
current_user– (Method) Returns the currently logged in user (usually an instance of
User) or a
GuestUserif there no currently logged in user.
logged_in?– (Method) Returns whether or not a user is currently logged in. (Guest users are not considered to be logged in)
Cms::ApplicationController is used by most of the ‘back-end’ admin controllers, which adds several filters that can be used for securing controllers based specifically on CMS permissions, including:
cms_access_required– (Filter) Asserts that the user must have management permissions (either Edit/Publish Content, or Administer the CMS).
All content is served to users via the
Cms::ContentController. When a user tries to access a page or file, the ContentController will check that the current user can view pages/files in that section. If it does not, it will raise a
Cms::Errors::AccessDenied error. For public users, the CMS will handle this error by rendering the ‘Access Denied’ page. The Access Denied page is an editable page within the CMS, where you can put a helpful error message and potentially add a
LoginPortlet so the user can login and get to the page they wanted to in the first place.