The best way in my opinion is as Pookey mentions - Client side SSL certificates.

Have a looksie at this how-to - it is very easy to set up.

http://blogs.ittoolbox.com/security/investigator/archives/howto-securing-a-website-with-client-ssl-certificates-11500

Steve Daniels

On 08/10/2007, Kiril Angov <[EMAIL PROTECTED]> wrote:
>
> I am using something similar to the solutions bellow and as I am not
> afraid of server admin I really agree it is a good solution. Though, as
> Lukas mentioned it was not obvious for everybody but I think all
> developers know how to manupulate the "hosts" file of their computer in
> order to developer whatever websites they work on.
>
> I think it is not unusual for people for do something like domain.com ->
> domain.local, right? So simply use one front controller and have inside:
>
> if ($_SERVER['HTTP_HOST'] == 'www.staging.com')
> {
>   define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
>   define('SF_APP',         'frontend');
>   define('SF_ENVIRONMENT', 'staging');
>   define('SF_DEBUG',       false);
> }
> else if ($_SERVER['HTTP_HOST'] == 'www.domain.local')
> {
>   define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
>   define('SF_APP',         'frontend');
>   define('SF_ENVIRONMENT', 'dev');
>   define('SF_DEBUG',       true);
> }
> else
> {
>   define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
>   define('SF_APP',         'frontend');
>   define('SF_ENVIRONMENT', 'prod');
>   define('SF_DEBUG',       false);
> }
>
> This has worked a charm for me as I want to be able to access both
> production and development at the same time. If there is interest I can
> make this a wiki page or Lukas while you are at it, you can do both?
>
> Good/Bad?
>
> Kupo
>
> Kris Wallsmith wrote:
> > Hi Lukas,
> >
> > I typically use the following front controller. This allows me to
> > define the bootstrap settings from w/i my Apache configuration,
> > preventing people from accessing the site in an alternate environment.
> >
> > Hope that helps!
> > Kris
> >
> > <pre><code>
> > <?php
> >
> > /** @version SVN: $Id$ **/
> >
> > define('SF_ROOT_DIR',       realpath(dirname(__FILE__).'/..'));
> > define('SF_APP',            isset($_SERVER['SF_APP']) ?
> > $_SERVER['SF_APP'] : 'frontend'));
> > define('SF_ENVIRONMENT',    isset($_SERVER['SF_ENVIRONMENT']) ?
> > $_SERVER['SF_ENVIRONMENT'] : 'prod');
> > define('SF_DEBUG',          isset($_SERVER['SF_DEBUG']) ? (bool)
> > $_SERVER['SF_DEBUG'] : false);
> >
> > require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
> >
> > sfContext::getInstance()->getController()->dispatch();
> >
> > </code></pre>
> >
> > On Oct 8, 5:08 am, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> >
> >> Hi,
> >>
> >> I have tried many approaches in order to be able to keep my
> >> development frontend files in a separate directory than the
> >> production frontends. This has the advantage that you can more easily
> >> prevent/secure access to the development frontend while still being
> >> able to keep the development frontends in svn without the danger of
> >> forgetting to remove these files when doing a checkout on the
> >> production machines. More importantly by making this separate
> >> directory with the development frontends available form the web, but
> >> with additional security precautions, its possible to use the
> >> development frontends on your production machines. The process to get
> >> there is unfortunately quite hacky. I am open for suggestions on how
> >> to improve the approach as its described below:
> >>
> >> In order to prevent end users from accessing development front
> >> controllers or other administrative tools, these files should be
> >> moved to a directory "admin" inside the root symfony directory. This
> >> will however break any assets from loading properly. The solution is
> >> to change the AssetHelper to use a different relative url in that
> >> case. The following steps are necessary for this:
> >>
> >> 1) Add a constant in the given front controllers that enables the
> >> host rewriting:
> >>
> >> define('SF_REWRITE_ASSET_HOST', true);
> >>
> >> 2) Add a filter that rewrites the location (for most applications
> >> there will be a need to initialize the session, making sure that non
> >> authenticated users are directed at the right page, that the language/
> >> country cookie is set properly etc., which seems like a goof location
> >> for this code):
> >>
> >> class initSessionFilter extends sfFilter
> >> {
> >>    /**
> >>     * Execute filter
> >>     *
> >>     * @param FilterChain $filterChain The symfony filter chain
> >>     */
> >>    public function execute($filterChain)
> >>    {
> >>      if ($this->isFirstCall()) {
> >>        $context  = $this->getContext();
> >>        $request  = $context->getRequest();
> >>        $user     = $context->getUser();
> >>        $action   = $context->getActionStack()->getLastEntry()-
> >>  >getActionInstance();
> >>
> >>        if (defined('SF_REWRITE_ASSET_HOST') && SF_REWRITE_ASSET_HOST) {
> >>          $asset_host = sfConfig::get('app_config_rewrite_asset_host');
> >>          if (substr($asset_host, 0, 4) === 'http') {
> >>            $request->setRelativeUrlRoot($asset_host);
> >>          } elseif (preg_match('/s(\/.+\/)(.*)/', $asset_host,
> >> $matches)) {
> >>            $request->setRelativeUrlRoot(preg_replace($matches[1],
> >> $matches[2], $request->getRelativeUrlRoot()));
> >>          } else {
> >>            $request->setRelativeUrlRoot($request->getRelativeUrlRoot
> >> ().$asset_host);
> >>          }
> >>        }
> >>        ..
> >>      }
> >>    }
> >>
> >> }
> >>
> >> 3) Add 'app_config_rewrite_asset_host' to your app.yml file
> >>
> >> all:
> >>    config:
> >> #   rewrite_asset_host:         'http://foo.bar'
> >> #   rewrite_asset_host:         's/admin\./'
> >>      rewrite_asset_host:         '/../web'
> >>
> >> Remember that you can have different configuration settings per
> >> environment and per server (following the above guidelines).
> >>
> >> There is a problem with this solution however if the no_script_tag
> >> feature is disabled, since in that case the url helpers will use the
> >> $request->getRelativeUrlRoot() to construct the url. In that case you
> >> also need to do some further hacking:
> >>
> >> 4) First you need to store the original relative url root in a
> >> constant before modifying the value in your filter. Then you need to
> >> open up and store lib/symfony/controller/sfWebController.class.php in
> >> your application lib directory and modify the genUrl() method. Look
> >> for the call to getRelativeUrlRoot() and change the section of the
> >> code as follows:
> >>
> >> $url = '';
> >> if (!sfConfig::get('sf_no_script_name'))
> >> {
> >>    $url = $this->getContext()->getRequest()->getScriptName();}
> >>
> >> else if ($sf_relative_url_root = $this->getContext()->getRequest()-
> >>  >getRelativeUrlRoot())
> >> {
> >>    $url = (defined('RELATIVE_ROOT_URL')) ? RELATIVE_ROOT_URL :
> >> $sf_relative_url_root;
> >>
> >> }
> >>
> >> regards,
> >> Lukas
> >>
> >
> >
> > >
> >
> >
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to