Well, I'll give a more detailed advice... Oh and it's a -1 : I'm afraid that wanting a controller "secured out of the box" is an error.
With a check based on IP you have the feeling of security, but this is a mistake as the IP is easy to change and fake. With such a solution, i'm very afraid of the side effect : instead of having people letting public "frontend_dev.php" file on their server and us telling them "be careful, this is dangerous", we will have people letting not-really-protected-but-seems-to "frontend_dev.php" on their server, and then we'll stop educating them. This will be included in the documentation as a secure protection, and everyone will have a feeling of security which will be simply false. I honestly prefer that the dev controllers stay how they are, and in the documentation just write in big & red that "Important Security Warning : dev controllers must not be deployed". No "out of the box" (which means : in PHP) solution will be really efficient to prevent access to a file which is in the Document Root. Such protections must be dedicated to the Web Server or the File System, PHP comes too late in the cycle to be efficient, and holes will still be exploitable. The only difference being that the user will *feel* secure. On 21 mai, 14:41, Kris Wallsmith <[EMAIL PROTECTED]> wrote: > Fair enough. Fabian's suggestion seems to be the best option on the > table. My only concerns are around when and how this array is built, > for what controllers, etc. If this logic is buried in the generate:app > task, we would be introducing hidden functionality. > > Introducing a generate:controller task is one option: > > ./symfony generate:controller --restrict=127.0.0.1 frontend dev > > or > > ./symfony generate:controller --restrict=conf/restrict_dev.txt > frontend dev > > The latter option reading each non-empty line of the referenced file > as an IP address. > > I'd be happy to submit a patch for this task, if it passes group > muster. > > Thanks, > Kris > > On May 20, 10:29 pm, Fabien Potencier <[EMAIL PROTECTED] > > > > project.com> wrote: > > Kris Wallsmith wrote: > > > Hm, sorry if I'm late to the conversation. How about not automatically > > > creating a _dev.php controller along with an app? > > > You always need a _dev.php controller to develop your application. So, > > we need to create the file by default. > > > This thread is not about the best practices on how to secure the > > _dev.php controllers because the best practices depends on your SCM, Web > > server, ... > > > We try to find a simple way to secure the _dev.php controllers by > > default, so that if you happen to deploy one _dev.php controller on the > > production servers, you're secure. > > > I really think that the Fabian proposal is easy, non obstrusive, and > > easy to customize. > > > Fabien > > > > Kris > > > > On May 20, 2:50 pm, "Ian P. Christian" <[EMAIL PROTECTED]> wrote: > > >> Kris Wallsmith wrote: > > >>> I typically deploy to production using a Subversion checkout. The only > > >>> controller I have in the repository is index.php, which is enforced by > > >>> a "*_*.php" svn:ignore property on the web directory. > > >>> Isn't this simple enough? > > >> No. For reasons already discussed in this thread - we want this secure > > >> out of the box. > > > -- > > Fabien Potencier > > Sensio CEO - symfony lead developer > > sensiolabs.com | symfony-project.com | aide-de-camp.org > > Tél: +33 1 40 99 80 80 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
