[nycphp-talk] single entry point
Michael
mogmios at mlug.missouri.edu
Tue Jul 30 22:01:51 EDT 2002
I'd say it's more of a design issue. The fewer possible places to leave
something out the fewer places you have to audit before you're sure
security is working. I've worked on sites that had been written over a
couple years time by dozens of programmers with dozens of modules and
nothing ever documented and so forth. Security was a nightmare to ensure.
By putting it all under the same tent to begin with then at least you can
ensure that security is working unless someone specificly disabled it.
> 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.
> > 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
> > > ______________________________________________________________
> > >
> > >
> > >
> > >
> >
> >
>
More information about the talk
mailing list