Download the PHP package fos1/sf-doctrine-guard-plugin without Composer

On this page you can find all versions of the php package fos1/sf-doctrine-guard-plugin. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package sf-doctrine-guard-plugin

sfDoctrineGuardPlugin

The sfDoctrineGuardPlugin is a symfony plugin that provides authentication and authorization features above and beyond the standard security features of symfony.

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 a configurable plugin.

Beginning with version 5.0.0 (the 1.4 stable branch), sfDoctrineGuardPlugin also provides the option of applying for an account through the site (this is disabled by default), and the ability to reset your password if you have forgotten it. For security, password reset requires that you know the email address associated with the account and be able to receive mail there. However applying for an account does not yet require receiving an email message in 5.0.0.

The 5.x series can require significant migration effort when moving from earlier releases. See the Upgrade section for more information.

Notes

This plugin was initially developer by Fabien Potencier for Symfony1 and later moved to GutHub and updated by LExpress group ()https://github.com/LExpress/sfDoctrineGuardPlugin).

Moving this plugin under the FriendsOfSymfony1 organization does not state that this module is currently maintained nor under active development. The aim is to provide a central place where the outdated plugins can be placed, to reduce the number of forks done by organizations that (for any contractual/weird/other reasons) have to maintain Symfony1 applications.

If you are planning a new project based on Symfony, use the latest and maintained Symfony release, you will ll not regret it ;)

Installation

Upgrading

The 5.0.x series adds several new tables, adds columns to existing tables and changes the names of all of the relations in the schema.

This requires changes of two kinds: database schema changes and, in some cases, changes to your code. We'll look at each of these issues in turn.

Updating your Schema

There are three basic changes in the schema:

Upgrading to 8 Byte Integers

It would be handy to use Doctrine's generate-migrations-diff task to update the schema, but unfortunately while it is a powerful tool it cannot figure out how to change the ID columns to 8 bytes without foreign key errors. You can write a migration yourself or just use SQL ALTER TABLE statements. If you choose to do so, you will need to drop the foreign key indexes first (never the columns of course, just the indexes), alter the ID column types, and then create the foreign key indexes again. We recommend locking the database while doing so.

You can also leave the types of the IDs alone in your existing database. That is a great deal easier. If you choose this approach, make sure you create the new sfGuardForgotPassword table with 4-byte integers, just like your old tables, as explained below.

Adding the New Columns

There are three new columns in the sf_guard_user table. You can add these with the following SQL statements:

ALTER TABLE sf_guard_user ADD COLUMN first_name varchar(255) DEFAULT NULL;
ALTER TABLE sf_guard_user ADD COLUMN last_name varchar(255) DEFAULT NULL;
ALTER TABLE sf_guard_user ADD COLUMN email_address varchar(255) DEFAULT '';

Next you should specify that the email address must be unique. This poses a problem if your users do not currently have an email address field at all in your existing system (for instance, you have no profile table, or there is no email address in it). You can work around it this way as a temporary solution:

UPDATE sf_guard_user SET email_address = username;

This ensures a unique setting although it does not actually provide a useful email address. If you have a profile table with email addresses, a better idea is to import your email addresses from there:

UPDATE sf_guard_user,sf_guard_profile SET sf_guard_user.email_address = sf_guard_profile.email_address WHERE sf_guard_user.id = sf_guard_profile.id;

Now you are ready to index the column and make it unique:

ALTER TABLE sf_guard_user ADD UNIQUE KEY `email_address` (`email_address`);
Adding the sfGuardForgotPassword table

You can do this with the following SQL code.

If you wish to stick with 4-byte IDs:

CREATE TABLE sf_guard_forgot_password (id INT AUTO_INCREMENT, user_id INT NOT NULL, unique_key VARCHAR(255), expires_at DATETIME NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, INDEX user_id_idx (user_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;

If you have upgraded your IDs:

CREATE TABLE sf_guard_forgot_password (id BIGINT AUTO_INCREMENT, user_id BIGINT NOT NULL, unique_key VARCHAR(255), expires_at DATETIME NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, INDEX user_id_idx (user_id), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ENGINE = INNODB;

Updating your Code

If you have not migrated your database schema yet, DO THAT FIRST (see above). Otherwise you lose the option of using Doctrine migrations.

After updating your schema you will also need to update your code to account for the changes.

First rebuild your model, form and filter base classes. This will not damage any custom code in your own model classes, as long as you followed standard practice and left the Base classes alone:

./symfony doctrine:build --all-classes

Second, check your Doctrine code for places where you use the relations that are defined for sfGuardUser, sfGuardGroup, etc. The names of these relations have been changed for convenience and to follow Symfony best practices.

The most frequently used relations that have changed are:

$group->users is now $group->Users (uppercase) $group->permissions is now $group->Permissions (uppercase) $user->groups is now $user->Groups (uppercase) $user->permissions is now $user->Permissions (uppercase)

The less commonly used relations on sfGuardUserPermission and sfGuardGroupPermission have changed as well. They are capitalized and they do not have an sfGuard prefix. Those who sometimes write custom queries to locate users with particular privileges need to be aware of this.

Secure your application

To secure a symfony application:

Manage your users, permissions and groups

To be able to manage your users, permissions and groups, sfDoctrineGuardPlugin comes with 3 modules that can be integrated in your backend application. These modules are auto-generated thanks to the symfony admin generator.

Applying for Accounts

Some site administrators will wish to allow members of the public to apply for accounts. Beginning in 5.0.0 this feature is available in sfDoctrineGuardPlugin.

To enable the feature you must enable the sfGuardRegister module, then provide users with a link to the sfGuardRegister/index action.

[TODO: flesh this out further] [TODO: document the forgot password feature]

Customize sfGuardAuth module templates

By default, sfGuardAuth module comes with 2 very simple templates:

If you want to customize one of these templates:

Customize sfGuardAuth module actions

If you want to customize or add methods to the sfGuardAuth:

sfGuardSecurityUser class

This class inherits from Symfony's sfBasicSecurityUser class and is used for the user object in your symfony application. (Remember that you changed the myUser base class earlier.)

To access it, you can use the standard $this->getUser() in your actions or $sf_user in your templates.

sfGuardSecurityUser adds some useful methods:

For example, to get the current username:

Superadmin ("super administrator") flag

To prevent chicken and egg problems, sfDoctrineGuardPlugin has the concept of a "superadmin." A user that is a superadmin bypasses all credential checks.

The superadmin flag cannot be set via the sfGuardUser admin module, you must set the flag directly in the database or use the provided Symfony task:

symfony guard:promote admin

Validators

sfDoctrineGuardPlugin comes with a validator that you can use in your modules: sfGuardUserValidator.

This validator is used by the sfGuardAuth module to validate the username and password before signing the user in.

Check the user password with an external method

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 your passwords in another table, you can provide your own checkPassword callable (static method or function) in app.yml:

all:
  sf_guard_plugin:
    check_password_callable: [MyLDAPClass, checkPassword]

When symfony will call the $this->getUser()->checkPassword() method, it will call your method or function. Your function must takes 2 parameters, the first one is the username and the second one is the password. It must return true or false. Here is a template for such a function:

Change the algorithm used to store passwords

By default, passwords are stored as a sha1() hash. But you can change this with any callable in app.yml:

all:
  sf_guard_plugin:
    algorithm_callable: [MyCryptoClass, MyCryptoMethod]

or:

all:
  sf_guard_plugin:
    algorithm_callable: md5

As the algorithm is stored for each user, you can change your mind later without the need to regenerate all passwords for the current users.

Change the name or expiration period of the "Remember Me" cookie

By default, the "Remember Me" feature creates a cookie named sfRemember that will last 15 days. You can change this behavior in app.yml:

all:
  sf_guard_plugin:
     remember_key_expiration_age:  2592000   # 30 days in seconds
     remember_cookie_name:         myAppRememberMe

Customize sfGuardAuth redirect handling

It is possible to redirect the user to his profile after a successful login, or to a particular page on logout.

You can change the redirect settings in app.yml:

all:
  sf_guard_plugin:
    success_signin_url:      @my_route?param=value # the plugin uses the referer as default
    success_signout_url:     module/action         # the plugin uses the referer as default

All versions of sf-doctrine-guard-plugin with dependencies

PHP Build Version
Package Version
Requires composer/installers Version ~1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package fos1/sf-doctrine-guard-plugin contains the following files

Loading the files please wait ....