NYCPHP Meetup

Tue Jul 30 10:40:23 EDT 2002

I will have to disaggree with your conclusion that this kind of a design will have major advantages regarding security.

You could just seperate you security page (that checks whether the user is signed in and has the required permissions) and include it in every page (maybe along with stuff that you include anyway. .like the <HTML><HEAD> stuff). 

I've found that what you're describing is good for template based sites. For instance on freelinuxcd.org I use a very simple implementation of this. All pages have the same table structure which keeps the look uniform, but depending on the 'page' variable passed, the appropriate CONTENT is displayed in the table cells. If you would like to take a look at the code it's in http://freelinuxcd.org/download/latest/. There's no authentication there simply because we have no use for it. 

Lastly, you can accomplish most of what you're describing by using a dummy frame that keeps the url unchanged no matter which page you go to.

cheers..

Oktay

On Tue, 30 Jul 2002 10:25:50 -0400
Jim Hendricks <jim at bizcomputinginc.com> wrote:

> 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
>  ______________________________________________________________
> 
> 
> 
> 

NYCPHP Meetup

NYPHP.org

[nycphp-talk] single entry point