Development

/plugins/sfGuardPlugin/README

You must first sign up to be able to contribute.

root/plugins/sfGuardPlugin/README

Revision 3187, 8.1 kB (checked in by fabien, 6 years ago)

removed module/action support for permission.

If you want to create a permission for a module, you can just
append the module name to the permission as a prefix.

So, to create a permission edit for module foo and bar, create 2 permissions
named edit_foo and edit_bar.

Line 
1 = sfGuard plugin =
2
3 !!! ALPHA RELEASE !!!
4
5 The `sfGuardPlugin` is a symfony plugin that provides authentication and authorization features above the standard security feature of symfony.
6
7 It gives you the model (user, group and permission objects) and the modules (backend and frontend) to secure your symfony application in a minute in
8 a configurable plugin.
9
10 == Installation ==
11
12   * Install the plugin
13  
14   {{{
15     symfony plugin-install http://plugins.symfony-project.com/sfGuardPlugin
16   }}}
17  
18   * Rebuild your model
19  
20   {{{
21     symfony propel-build-all
22   }}}
23  
24   * Load default fixtures (optional - it creates a superadmin user)
25  
26   {{{
27     symfony propel-load-data
28   }}}
29  
30   * Enable one or more modules in your `settings.yml` (optional)
31     * For your backend application:  sfGuardUser, sfGuardGroup, sfGuardPermission
32     * For your frontend application: sfGuardAuth
33
34   {{{
35     all:
36       .settings:
37         enabled_modules:      [default, sfGuardGroup, sfGuardUser, sfGuardPermission]
38   }}}
39
40   * Clear you cache
41  
42   {{{
43     symfony cc
44   }}}
45
46 === Secure your application ===
47
48 To secure a symfony application:
49
50   * Enable the module `sfGuardAuth` in `settings.yml`
51
52   {{{
53     all:
54       .settings:
55         enabled_modules: [..., sfGuardAuth]
56   }}}
57
58   * Change the default login and secure modules in `settings.yml`
59
60   {{{
61     login_module:           sfGuardAuth
62     login_action:           signin
63
64     secure_module:          sfGuardAuth
65     secure_action:          secure
66   }}}
67
68   * Change the user class in `factories.yml`
69
70   {{{
71     all:
72       user:
73         class: sfGuardSecurityUser
74   }}}
75
76   * Add the following routing rules to `routing.yml`
77
78   {{{
79     sf_guard_signin:
80       url:   /login
81       param: { module: sfGuardAuth, action: signin }
82
83     sf_guard_signout:
84       url:   /logout
85       param: { module: sfGuardAuth, action: signout }
86
87     sf_guard_password:
88       url:   /request_password
89       param: { module: sfGuardAuth, action: password }
90   }}}
91
92   You can customize the `url` parameter of each route.
93   N.B.: You must have a `@homepage` routing rule (used when a user sign out)
94
95   * Secure some modules or your entire application in `security.yml`
96
97   {{{
98     default:
99       is_secure: on
100   }}}
101
102   * You're done. Now, if you try to access a secure page, you will be redirected to the login page.
103     If you have loaded the default fixture file, try to login with `admin` as username and `admin` as password.
104
105 == Manage your users, permissions and groups ==
106
107 To be able to manage your users, permissions and groups, `sfGuardPlugin` comes with 3 modules that can be integrated in your backend application.
108 These modules are auto-generated thanks to the symfony admin generator.
109
110   * Enable the modules in `settings.yml`
111
112   {{{
113     all:
114       .settings:
115         enabled_modules: [..., sfGuardGroup, sfGuardPermission, sfGuardUser]
116   }}}
117
118   * Access the modules with the default route:
119  
120   {{{
121     http://www.example.com/backend.php/sfGuardUser
122   }}}
123
124 == Customize sfGuardAuth module templates ==
125
126 By default, `sfGuardAuth` module comes with 2 very simple templates:
127
128   * `signinSuccess.php`
129   * `secureSuccess.php`
130
131 If you want to customize one of these templates:
132
133   * Create a `sfGuardAuth` module in your application
134  
135   * Create a template with the name of the template you want to customize in your `templates` directory
136
137   * Symfony now renders your template instead of the default one
138
139 == Customize `sfGuardAuth` module actions ==
140
141 If you want to customize or add methods to the sfGuardAuth:
142
143   * Create a `sfGuardAuth` module in your application
144  
145   * Create an `actions.class.php` file in your `actions` directory that inherit from `BasesfGuardAuthActions`
146
147   {{{
148     <?php
149
150     class sfGuardAuthActions extends BasesfGuardAuthActions
151     {
152       public function executeNewAction()
153       {
154         return $this->renderText('This is a new sfGuardAuth action.');
155       }
156     }
157   }}}
158
159 == `sfGuardSecurityUser` class ==
160
161 This class inherits from the `sfBasicSecurityUser` class from symfony and is used for the `user` object in your symfony application
162 (because you configured it in `factories.yml` before).
163
164 So, to access it, you can use the standard `$this->getUser()` in your actions or `$sf_user` in your templates.
165
166 `sfGuardSecurityUser` adds some methods:
167
168   * `signIn()` and `signOut()` methods
169   * `getGuardUser()` that returns the `sfGuardUser` object
170   * a bunch of proxy methods to access directly the `sfGuardUser` object
171
172 For example, to get the current username:
173
174   {{{
175     $this->getUser()->getGuardUser()->getUsername()
176
177     // or via the proxy method
178     $this->getUser()->getUsername()
179   }}}
180
181 == Super administrator flag ==
182
183 `sfGuardPlugin` has a notion of super administrator. A user that is a super administrator bypasses all credential checks.
184
185 The super administrator flag cannot be set on the web, you must set the flag directly in the database or use the pake task:
186
187   {{{
188     symfony promote-super-admin admin
189   }}}
190
191 == Validators ==
192
193 `sfGuardPlugin` comes with a validator that you can use in your modules: `sfGuardUserValidator`.
194
195 This validator is used by the `sfGuardAuth` module to validate a user and password and automatically signin the user.
196
197 == Customize the `sfAuthUser` model ==
198
199 The `sfAuthUser` model is quite simple. There is no `email` or `first_name` or `birthday` columns.
200 As you cannot add methods to the class, the `sfAuthPlugin` gives you the possibility to define a user profile class.
201
202 By default, `sfAuthUser` looks for a `sfGuardUserProfile` class.
203
204 Here is a simple example of a `sfGuardProfile` class that you can add to `schema.yml`:
205
206   {{{
207     sf_guard_user_profile:
208       _attributes: { phpName: sfGuardUserProfile }
209       id:
210       user_id:     { type: integer, index: unique }
211       first_name:  varchar(20)
212       last_name:   varchar(20)
213       birthday:    date
214   }}}
215
216 WARNING: You cannot define the foreign key because the `sf_guard_user` table is not in the same schema file (this is a Propel limitation).
217
218 This is why we added a unique index to the `user_id` column.
219
220 You can now access the user profile via the user object:
221
222   {{{
223     $this->getUser()->getGuardUser()->getProfile()->getFirstName()
224
225     // or via the proxy method
226     $this->getUser()->getProfile()->getFirstName()
227   }}}
228
229 The `getProfile()` method gets the associated user profile object or creates a new one if none already exists.
230
231 When you delete a user, the associated profile is also deleted.
232
233 You can change the name of the user profile class and the foreign key name in `app.yml`:
234
235   {{{
236     all:
237       sf_guard_plugin:
238         profile_class:      sfGuardUserProfile
239         profile_field_name: user_id            # we have to define this (see warning above)
240   }}}
241
242 == Check the user password with an external method ==
243
244 If you don't want to store the password in the database because you already have a LDAP server, a .htaccess file or if you store
245 your passwords in another table, you can provide your own `checkPassword` callable (static method or function) in `app.yml`:
246
247   {{{
248     all:
249       sf_guard_plugin:
250         check_password_callable: [MyLDAPClass, checkPassword]
251   }}}
252
253 When symfony will call the `$this->getUser()->checkPassword()` method, it will call your method or function. Your function must takes 2 parameters,
254 the first one is the username and the second one is the password. It must returns true or false. Here is a template for such a function:
255
256   {{{
257     function checkLDAPPassword($username, $password)
258     {
259       $user = LDAP::getUser($username);
260       if ($user->checkPassword($password))
261       {
262         return true;
263       }
264       else
265       {
266         return false;
267       }
268     }
269   }}}
270
271 == Change the algorithm used to store passwords ==
272
273 By default, passwords are stored as a `sha1()` hash. But you can change this with any callable in `app.yml`:
274
275   {{{
276     all:
277       sf_guard_plugin:
278         algorithm_callable: [MyCryptoClass, MyCryptoMethod]
279   }}}
280
281 or
282
283   {{{
284     all:
285       sf_guard_plugin:
286         algorithm_callable: md5
287   }}}
288
289 As the algorithm is stored for each user, you can change your mind later without the need to regenerate all passwords
290 for the current users.
291
292 == TODO ==
293
294   * finish the `promote_super_user` task
295   * finish the `getPassword` method
296   * add support for HTTP Basic authentication
297   * add a "remember me" feature?
Note: See TracBrowser for help on using the browser.