A short blurb on using sfGuardPlugin credentials
post-template-default,single,single-post,postid-15634,single-format-standard,bridge-core-3.0.1,qodef-qi--touch,qi-addons-for-elementor-1.5.3,qode-page-transition-enabled,ajax_updown,page_not_loaded,,vertical_menu_enabled,no_animation_on_touch,side_area_uncovered_from_content,qode-theme-ver-28.7,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,wpb-js-composer js-comp-ver-6.8.0,vc_responsive,elementor-default,elementor-kit-6

A short blurb on using sfGuardPlugin credentials

A short blurb on using sfGuardPlugin credentials

(Here are a few notes I made to myself about the credential system.)

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 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:

   secure: on

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

   credential: can_view_items
   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