|
|
sfSslRequirementExtraPlugin - 1.0.0SSL integration plugin with versatile configuration. |
|
 |
2
users
Sign-in
to change your status |
Configure SSL requirements for your module/actions in a static or dynamic way. Based on sfSslRequirementPlugin. |
Enhance your application security, using ssl protocol only when needed, via a fully parametrized architecture. This plugin is based on sfSslRequirementPlugin, adding new capabilities.
| Name | Status | |
|---|---|---|
vasil g |
lead | moc.liamg <<ta>> ailexon |
Copyright (c) 2004-2012 Fabien Potencier, basos g
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
| Version | License | API | Released |
|---|---|---|---|
| 1.0.0stable | MIT license | 1.0.0stable | 09/03/2012 |
Initial import, lots of enhanchements based on sfSslRequirementPlugin
Initial import, lots of enhanchements based on sfSslRequirementPlugin
The sfSslRequirementExtra is a symfony plugin that provides SSL integration for your application. Note that you should already have a webserver configured with ssl.
It gives you 3 new security settings (specified in module's security.yml): require_ssl, allow_ssl and generate_ssl, allowing you to fully configure ssl requirement during url matching as well as url generation. Read more for explanations.
The plugin also adds 3 new sfAction methods (via the mixins design pattern): ->sslRequired(), ->sslAllowed(), ->sslGenerate().
Install the plugin via plugin install
$ symfony plugin:install sfSslRequirementExtraPlugin
or via svn checkout
$ cd plugins; svn co http://svn.symfony-project.com/plugins/sfSslRequirementExtraPlugin/trunk sfSslRequirementExtraPlugin
Enable sfSslRequirementExtraPlugin (if not automatically enabled) @ config/ProjectConfiguration.class.php
public function setup() { $this->enablePlugins( array('sfSslRequirementExtraPlugin')); }
Activate the filter in your filters.yml (for ssl requirement during url matching)
[...] sfSslRequirementExtra: class: sfSslRequirementFilter cache: ~ execution: ~
Setup the routing factory in your factories.yml (for ssl requirement during url generation, i.e. when generate_ssl security option is set).
routing: class: sfSslPatternRouting
Clear your cache
$ symfony cc
To force SSL on an module/action (with GET http method):
Add the following snippet to the module's security.yml (under appdir/moduleName/config):
actionName: require_ssl: true
You're done. Now, if you try to access the actionName with HTTP, you will be automatically redirected to HTTPS.
NOTE: The actionName listed here is an example. Substitute with your actual action name.
Until this point you would be fine with forcing HTTPS for GET actions. What about forcing HTTP, allowing both HTTP and HTTPS or controlling ssl requirements for POST actions? You can configure sfSslRequirementExtra plugin more precicely to fullfill these requirements.
SSL requirements can be configured per module or per module/action basis. To configure the hole module just add the configuration entries under all: key in the module's security.yml. To configure one module's action add the configuration entries under actionName: key in the module's security.yml.
The supported configuration directives for the security.yml, with their default values, are:
all: require_ssl: false allow_ssl: false generate_ssl: false
Explanations:
allow_ssl and require_ssl configuration directives. Note that you should have set the correct routing factory for this to work, as described in the installation steps.During URL matching,
if (not POSTing)
if (not secured [HTTP])
if (require_ssl)
redirect to HTTPS
elseif (secured [HTTPS])
if (not allow_ssl)
redirect to HTTP
elseif (POSTing and strict_post = true)
if (not secured [HTTP])
if (require_ssl)
throw logical exception (misconfiguration)
During URL generation
if (generate_ssl)
if (require_ssl)
if (not request has ssl)
if (route absolute)
write secure url (HTTPS)
else
throw logical exception (route should be generated absolutely)
elseif (not allow_ssl)
if (request has ssl)
if (route absolute)
write non-secure url (HTTP)
else
throw logical exception (route should be generated absolutely)
Some options can be configured for the hole plugin. These are specified in app.yml (application or global) and are the following (with the default values shown):
all:
sfSslRequirementExtraPlugin:
# completely disable ssf requirement plugin
disable: false
# if set, an exception is thrown when insecure post data have been POSTed
strict_post: true
Notes:
Strict posting (true by default) would throw a runtime exception when data that should be transmitted securely where already sent over plain http. This does not prevent data exposure, in the first time, but pinpoints the misconfiguration to the developer. The solution to this is to secure the POST action (with require_ssl=true) and generate the url in an absolute way. To do this in a template you could write:
url_for('route_name', array(route_params), true) link_to('Text', 'route_name', array('absolute'=>true))
You can skip this behaivour by specifying strict_post=false in the app.yml.
Until this point you have configured all the aspects of ssl requirements during url matching or generation in a static manner. But what about if you want to require ssl on an action only when the user is authenticated? (This would make sense when you want to serve your content at your authenticated users securely, and serve the same content non-securely at guests). Or if you would like to control ssl requirement depending on request parameters. (This would make sense when you use the same action to serve content for different purposes, like atom feeds. In this case the sf_format parameter differentiates the 2 scenarios)
To accomplish these and other cases where dynamic configuration of the ssl requirements is needed you should follow these steps:
Create a file named sslDynConfig.class.php under moduleName/config directory (the same dir whe security.yml lives).
In this file, declare a class named <moduleName>ActionsSslDynConfig that implements the actionsSslDynConfigIface interface:
/** * This interface must be implemented from <moduleName>ActionsSslDynConfig classes for each * module that needs to provided dynamic ssl requirement configuration */ interface actionsSslDynConfigIface { /** * Called from sf_ssl_requirement plugin, to dynamically configure it during URL MATCHING * * @param string $actionName * @param sfAction $actionInstance * @return array */ public function getSslRequirementMatchDynamicConfig( $actionName, $actionInstance ); /** * Called from sf_ssl_requirement plugin, to dynamically configure it during URL GENERATION * * @param string $actionName * @param array $routeParams * @return array */ public function getSslRequirementGenerateDynamicConfig( $actionName, $routeParams ); }
Dynamic configuration is done seperately for URL MATCHING and URL GENERATION with the ->getSslRequirementMatchDynamicConfig() and ->getSslRequirementGenerateDynamicConfig() methods, respectivelly. Note that it is not mandatory (and possible) to define the same dynamic configuration for URL matching and generation for a specific action.
Dynamic configuration has higher priority than the static configuration (defined in security.yml).
WARNING: Dynamic configuration can damage your brain, use with caution.
Implement the logic on these methods and return an array of ssl requirement configuration parameters (as described in "Ssl Requirements Configuration" section above).
For URL MATCHING you have the $actionName and $actionInstance parameters. Note that the getSslRequirementMatchDynamicConfig() should always return an array, exluding the generate_ssl parameter (as this does not have meaning during url matching).
An example: You want to require_ssl for the index action when sf_format is not atom (i.e. for normal html content) and when the user is authenticated. Moreover you want to require_ssl on the show action when the user is authenticated. This is how to do it:
public function getSslRequirementMatchDynamicConfig( $actionName, $actionInstance ) { $request = $actionInstance->getRequest(); $user = $actionInstance->getUser(); switch ($actionName) { case 'index': if ($request->getParameter('sf_format') !== 'atom' && $user->isAuthenticated() ) return array('require_ssl'=>true); break; case 'show' : if ($user->isAuthenticated()) return array('require_ssl'=>true); break; } // no dynamic config return array(); }
For URL GENERATION you have the $actionName and the $routeParams array parameters. Note that the getSslRequirementGenerateDynamicConfig() should always return an array.
An example: You want to generate the route for the index action with non-secure protocol, when the sf_format is atom. I.e. you want the atom feed links to always be in http, irrelevant of the current request protocol. This is how to do it:
public function getSslRequirementGenerateDynamicConfig($actionName, $routeParams) { switch ($actionName) { case 'index': // on index, format atom, generate ssl (dissallow ssl) if (isset($routeParams['sf_format']) && $routeParams['sf_format'] === 'atom') { return array('generate_ssl'=>true); } break; } // no dynamic config return array(); }
These are some classic examples where dynamic configuration of the ssl requirements is usefull. Feel free to use it for any other schenario it might fit your needs.
