UserFrosting is a system that centers around user accounts and user management. It currently supports the following features:
rootmaster account with unlimited privileges
A user can belong to one or more groups, which determines which resources on your site they can access.
Users can also be assigned a primary group, which is used to determine their theme and other aspects of their experience.
UserFrosting uses a (nearly) RESTful URL naming scheme. REST means that URLs are designed to refer to specific resources, which can be retrieved (via a
GET request) or modified (via a
POST request). UserFrosting does not use the
DELETE HTTP methods, as these are not widely supported by browsers.
GET /users // List users GET /users/u/1 // View info for user 1 POST /users // Create a new user POST /users/u/1 // Update info for user 1 POST /users/u/1/delete // Delete user 1 (this is not RESTful, but many browsers still don't support DELETE) GET /forms/users/u/1?mode="view" // Get a form to view user info for user 1 GET /forms/users/u/1?mode="update" // Get a form to update user info for user 1 GET /forms/users // Get a form to create a new user
UserFrosting keeps everything that it needs for a user session in the
$_SESSION["userfrosting"] key. This includes the following:
Userobject for the currently logged-in user. Can also be accessed via
MessageStreamobject, that stores persistent messages. Can also be accessed via
$_SESSION["userfrosting"]["captcha"]: The most recently generated captcha code, used to verify new account registration.
UserFrosting 0.3.0 uses the same robust authentication system, with Blowfish password hashing. Password resets are done via a short-term expiring token.
Any visitor to your site who is not logged in is considered a "guest user". This means that there is no longer any need to do a separate check to see if a user is logged in - the controller can simply check if a user is authorized.
By default, the guest user is not authorized to do anything.
Themes allow custom css and layouts for different groups and users. Twig templates, in essence, already support this via an elegant system of template directories.
Our theming system consists of a separate folder for each theme, which contains one or more HTML template files and a theme stylesheet,
css/theme.css. This stylesheet is imported into the public folder via a special route. The default theme is
default, and other themes work by overriding this content. UF will by default look in the
default theme for template files if if cannot find them in the current theme.
If you want to completely change the content of a page for a particular group, you should make a completely new page and then set permissions appropriately. If you just want to change the layout and style of a page, then you should use a theme to override an existing page.
Session alerts can be retrieved on the client side through the
/alerts route. Messages are sent back to the client in this manner, rather than directly through the HTTP response body, because in some cases we will want to persist messages across one or more requests.
For example, after an AJAX request, you may want to refresh the page and then display the alerts. If the messages were directly part of the HTTP response from the AJAX request, they would be lost after the page refresh.
Internationalization is handled essentially the same way that it was in UserCake - through an array that maps message ids to messages in a particular language. In UserFrosting, this is handled through the static class
UserFrosting uses named placeholders with the double-handlebar notation
instead of UserCake's old
%m1% syntax. Translation is performed using the static
MessageTranslator::translate("MESSAGE_ID", [ "placeholder1" => "value1", "placeholder2" => "value2")]);
MESSAGE_ID is defined as "This is the message, which references and .", the output will be:
"This is the message, which references value1 and value2."
Messages can be automatically translated and pushed to the message stream using
$ms->addMessageTranslated("info", "MESSAGE_ID", [ "placeholder1" => "value1", "placeholder2" => "value2")]);
UserFrosting uses the Fortress project to provide a schema-based system for sanitizing and validating user data. This schema consists of a simple JSON file, with rules for how each user-submitted field should be processed.
HTTPRequestFortress class handles backend sanitization and validation, while the
We are currently in the process of developing a plugin system, to make it easy for developers to extend UserFrosting via modular components.