The accompanying VirtualHost block for my development environment
looks like this ...
<VirtualHost *:80>
ServerName domain.com
ServerAlias www.domain.com
ErrorLog logs/domain_com-error.log
CustomLog logs/domain_com-access.log common
DocumentRoot /var/www/vhosts/domain.com/web
<Directory /var/www/vhosts/domain.com/web>
Order allow,deny
Allow from all
Options +FollowSymLinks +ExecCGI
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]
</Directory>
Alias /sf /var/www/vhosts/domain.com/lib/vendor/symfony/data/web/sf
<Directory /var/www/vhosts/domain.com/lib/vendor/symfony/data/web/
sf>
Order allow,deny
Allow from all
</Directory>
SetEnv SF_APP frontend
SetEnv SF_ENVIRONMENT dev
SetEnv SF_DEBUG 1
</VirtualHost>
I should credit Chris Peery at Infernal Machinery for the SetEnv
solution. Also, I believe Dave Dash suggested moving the mod_rewrite
configuration to the VirtualHost block in a blog post at some point.
Thanks,
Kris
On Oct 8, 6:12 am, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
> On 08.10.2007, at 15:07, Stefan Koopmanschap wrote:
>
>
>
> > We currently have a different approach. All our _dev files are outside
> > the web directory. That way, it will never be available on our
> > production machines. If we need it on production for debugging
> > purposes, we simply temporarily copy/symlink the _dev file inside the
> > web directory, and once we're done, we remove the file.
>
> > To prevent accidental deployment of _dev files to production, we also
> > have them (inside the web directory) excluded from rsyncing. Our
> > deployment strategy is not to checkout on production, but to checkout
> > locally and use the symfony sync command to deploy to the production
> > environment.
>
> > Hopefully this is helpful?
>
> hmm not really. i think kris's approach is the most viable approach
> for me atm. symlinking would be a problem. a hacker could then just
> try to create some issue on the web site and wait for the development
> frontend to become available. actually i would not be surprised if
> hackers already have scanners that look for development frontends for
> symfony (or any other framework that has similar capabilities).
>
> 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
-~----------~----~----~----~------~----~------~--~---