NYCPHP Meetup

[Oktay Altunergil]

As one of the disaggreing people :), I'd like to mention again that there's no automatic security advantage to designing a site with a single entry point that I can think of. 

Oktay

On Tue, 30 Jul 2002 21:37:43 -0400
Michael <mogmios at mlug.missouri.edu> wrote:

> I'll step out on a limb and disagree with the others that responded to
> your message. I've written some very large PHP-based sites and from my
> experiences I've learned to base any sites of any size off a moduler
> single entry point design. For an example of the framework I created for
> my own use try http://freshmeat.net/projects/kfl/ and see my newest
> version.
> 
> I do not suggest that using a single entry point design is reasonable for
> every project. Small sites don't really benefit from the more structured
> design. Also a single entry point site can be designed totally without
> enternal structure which is just a mess. It can also be beneficial to have
> several 'single entry points' to group modules as is practical for your
> problem domain.
> 
> As someone else said templates are a good design choice for use with
> single entry points. IMO so are object oriented modules. Good object
> oriented design will make it easier to maintain security and
> maintainability as the site growsbut by no means will do your job for you.
> 
> There is no reason why search engines won't or can't spider as deep as you
> want even with a single entry point. It's a pretty easy trick to pass PHP
> arguments in the URL path. For example index.php?module=logon can be done
> as index.php/module/logon or just index.php/logon if you wanted.. hiding
> the fact that the requested files are dynamic from the search engines.
> 
> 
> > As a fairly new PHP developer, I'm wrestling with not only learning the
> > lingo, but also attempting to discover best practice.  When I was first
> > faced with ASP when ASP was first introduced I made the design snafu of
> > developing my first small page as a single page.  Login, login validation,
> > form entry, form validation and submission, and submission response all
> > rolled up into 1 .asp file.  While it was great for this 1 small app ( more
> > of an applet ), when the client wanted to add more stuff it required
> > re-arranging the app splitting it up, figuring out the then flawed
> > response.redirect etc.  It then required adding to the top of each page the
> > security checks to ensure the user was logged in etc. ( of course added as
> > an include ).
> >
> > Well to make a short story long, I encountered an ASP app written by another
> > programmer which I was inheriting which used a single entry point(
> > everything went through default.asp ( ASP's equivalent of index.php ) ).  He
> > used an encrypted querystring parameter to key the ASP file as to which page
> > was really required & then using a case statement included the necessary
> > files.  He must not have been aware of ASP's static include, all includes
> > are included regardless of control logic around the include.  I did think
> > the solution to be rather elegant, hiding the implementation from the user
> > by only exposing 1 page.  Later as I developed it I even moved the encrypted
> > parameter to a hidden form field to even hide that part of the
> > implementation.
> >
> > I've seen a few PHP apps floating around that use a similar design.  In PHP
> > the obvious advantage over the ASP version is the dynamic include ( include
> > based on the surounding logic ).  I'm interested to get the opinion of more
> > experienced PHP developers on this single entry point design.  I realize
> > this design will not allow search engines to index more than the entry
> > point, but I'm developing in an extranet environment where search engines
> > are not desired anyway.
> >
> > I think one of the things that draws me to this solution is the ease of
> > security checks and forcing a specific modality ( ie. stopping the browsers
> > back button & ensuring a specific work flow where required ).
> >
> > Please let me know your opinion on this.
> >
> > Jim
> >
> > _____________________________________________________________
> > Jim Hendricks, President, Biz Computing, Inc
> > Phone:  (201) 599-9380     Email: jim at bizcomputinginc.com
> > Web: www.bizcomputinginc.com
> > Snail:  Jim Hendricks,  Biz Computing, Inc.,  255 McKinley Ave, New Milford,
> > NJ 07646
> >  ______________________________________________________________
> >
> >
> >
> >
> 
>