Credentials are part of the sfGuardPlugin security system for Symfony. For some reason, Symfony also refers to credentials as permissions. As far as I can tell, the two terms are used interchangeably.

sfGuardUser records are stored in the sf_guard_user table.

The tables in the sfGuard permission system are:

• sf_guard_permission <- represents a permission (credential)
• sf_guard_group <- represents a group.
• sf_guard_group_permission <- associates permissions to groups
• sf_guard_user_group <- associates users to groups

Typcially, users belong to one or more groups, and groups are associated to permissions. This is the preferred method, and the above 4 tables are all that is needed to associate permissions to users, via groups.

It is possible (but not usually advisable) to associate a user directly with a permission by using the following table:

• sf_guard_user_permission <- associates users to permissions

Permissions

Permissions typically represent what a user can do, as opposed to representing a “type” of user. Examples of proper permissions are:

• can_view_items
• can_edit_items

The following are improper permissions because they represent user types:

• paying_clients
• non_paying_clients

Restricting actions via security.yml

For credentials to work, the user must be logged in. Since an application is divided into modules, it is conventional to divide modules into those that don’t require a logged-in user (i.e. fully public pages, such as main/aboutUs or main/termsAndConditions), and those modules that do require a logged-in user.

To require a login for a module, add the following into the module’s config/security.yml file:

 all:
   secure: on

For the most part, permissions are assigned to specific actions. For example:

 listItems:
   credential: can_view_items

 editItem:
   credential: can_edit_items

Using permissions within actions

 public function executeIndex( )
 {
   $user = $this->getUser();

   if($user->has_credential('can_view_items') )
   {
     // get the item list
     ...
   }

   ... and so forth
 }

indexSuccess:
  http_metas:
    refresh: 300

which results in adding the following, as you would expect:

<meta http-equiv="Refresh" content="300" />

Anyway, here are a couple of pictures showing custom menus for a small project. This allows me to find and load module templates, action files, and models quickly and easily.

 

 

OK, I didn’t write the script in elisp. Instead, I use perl to generate the elisp code. To create the elisp code, I run this script at the root of the Symfony project.

Update: After I wrote my implementation, I found this pure elisp implementation that creates an even better symfony navigation: http://svn.tracfort.jp/svn/dino-symfony/emacs-symfony/emacs-symfony/symfony-navigation.el