user login and access + headers already sent
in [General]
|
Prev: Recent Influx of Unrelated Discussions
Next: Determining the similarity between a user supplied short piece of text (between 5 and 15 characters) and a list of similar length text items.
From: Paul M Foster on 15 Jul 2010 12:22 On Thu, Jul 15, 2010 at 04:56:50PM +0100, Ashley Sheridan wrote: > On Thu, 2010-07-15 at 15:38 +0000, Carlos Sura wrote: > > > Hello mates, I'm developing a user registration and access level system... > > > > And I wonder... Is there any way to avoid to put code in every header page? > > Because, almost every page contains javascript, so almost every > page cotains <html> tags... And its annoying to look at this: Warning: > session_start(): Cannot send session cache limiter - headers already sent > > > > So, I'm wondering, is there any other way to avoid put code in every > page? or... another way to avoid that kind of error. > > > > > > Thank you. > > > > _________________________________________________________________ > > Got a cool Hotmail story? Tell us now > > http://clk.atdmt.com/UKM/go/195013117/direct/01/ > > > A key concept to remember is that HTML is inserted into your PHP code, > and not the other way around. Once I realised the difference, I found I > was making the header/output mistake far less often. > > Anyway, to answer the question, what most apps/websites do for this is > to use controller code to load in the correct HTML as necessary. The > first lines of most of my apps are general include lines. One for DB, > one for other config, etc. That way, I can just use the include files > for doing things that need to be done for every page. > > Common logic for a login is to use an include file that does this: > > > 1. Is user logged in? Yes: goto 5. No: goto 2 > 2. Have login details been submitted through form or other? Yes: > goto 3. No: goto 4 > 3. Are login details correct? Yes: goto 5, No: goto 4 > 4. Show login form & stop > 5. Show/redirect to app page > > (apologies for the hard to follow list, but I just realised I don't know > a good way to show a flowchart in plain text!) > > Use include files for your HTML headers, and only include them after > you've done everything you need to with session_start() and header() > calls. If there's content that changes in the header from page to page, > put that in a variable that you use in the included file. +1 Let me amplify this by suggesting that you minimize the PHP code inside your HTML. Like this: 1. Load your main PHP file. Do any calculations, etc., in it. 2. At the end of that file, load in a generic HTML template file. This file would contain everything from the <html> tag to the </html> tag. 3. Inside your template file, make a call to a "view" file, which is unique for this page. It should contain all the HTML code outside the actual template. In this file, make whatever PHP code limited to echoing values and loops. The values displayed, etc., are formulated in the original PHP file. That's one way to do it. Paul -- Paul M. Foster
From: Carlos Sura on 15 Jul 2010 12:56 Hello paul, thank you for your answer. I'm already fixing all my mess with your suggestions. It is nice to know where to ask to get a good answer. Regards, Carlos Sura. > Date: Thu, 15 Jul 2010 12:22:23 -0400 > From: paulf(a)quillandmouse.com > To: php-general(a)lists.php.net > Subject: Re: [PHP] user login and access + headers already sent > > On Thu, Jul 15, 2010 at 04:56:50PM +0100, Ashley Sheridan wrote: > > > On Thu, 2010-07-15 at 15:38 +0000, Carlos Sura wrote: > > > > > Hello mates, I'm developing a user registration and access level system... > > > > > > And I wonder... Is there any way to avoid to put code in every header page? > > > Because, almost every page contains javascript, so almost every > > page cotains <html> tags... And its annoying to look at this: Warning: > > session_start(): Cannot send session cache limiter - headers already sent > > > > > > So, I'm wondering, is there any other way to avoid put code in every > > page? or... another way to avoid that kind of error. > > > > > > > > > Thank you. > > > > > > _________________________________________________________________ > > > Got a cool Hotmail story? Tell us now > > > http://clk.atdmt.com/UKM/go/195013117/direct/01/ > > > > > > A key concept to remember is that HTML is inserted into your PHP code, > > and not the other way around. Once I realised the difference, I found I > > was making the header/output mistake far less often. > > > > Anyway, to answer the question, what most apps/websites do for this is > > to use controller code to load in the correct HTML as necessary. The > > first lines of most of my apps are general include lines. One for DB, > > one for other config, etc. That way, I can just use the include files > > for doing things that need to be done for every page. > > > > Common logic for a login is to use an include file that does this: > > > > > > 1. Is user logged in? Yes: goto 5. No: goto 2 > > 2. Have login details been submitted through form or other? Yes: > > goto 3. No: goto 4 > > 3. Are login details correct? Yes: goto 5, No: goto 4 > > 4. Show login form & stop > > 5. Show/redirect to app page > > > > (apologies for the hard to follow list, but I just realised I don't know > > a good way to show a flowchart in plain text!) > > > > Use include files for your HTML headers, and only include them after > > you've done everything you need to with session_start() and header() > > calls. If there's content that changes in the header from page to page, > > put that in a variable that you use in the included file. > > +1 > > Let me amplify this by suggesting that you minimize the PHP code inside > your HTML. Like this: > > 1. Load your main PHP file. Do any calculations, etc., in it. > 2. At the end of that file, load in a generic HTML template file. This > file would contain everything from the <html> tag to the </html> tag. > 3. Inside your template file, make a call to a "view" file, which is > unique for this page. It should contain all the HTML code outside the > actual template. In this file, make whatever PHP code limited to echoing > values and loops. The values displayed, etc., are formulated in the > original PHP file. > > That's one way to do it. > > Paul > > -- > Paul M. Foster > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > _________________________________________________________________ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/
From: tedd on 16 Jul 2010 12:43
At 4:56 PM +0100 7/15/10, Ashley Sheridan wrote: >On Thu, 2010-07-15 at 15:38 +0000, Carlos Sura wrote: > > > So, I'm wondering, is there any other way to avoid put code in >every page? or... another way to avoid that kind of error. >> >Common logic for a login is to use an include file that does this: > > > 1. Is user logged in? Yes: goto 5. No: goto 2 > 2. Have login details been submitted through form or other? Yes: > goto 3. No: goto 4 > 3. Are login details correct? Yes: goto 5, No: goto 4 > 4. Show login form & stop > 5. Show/redirect to app page > >(apologies for the hard to follow list, but I just realised I don't know >a good way to show a flowchart in plain text!) Flowchart? How about: 1. Is user logged-in? No, go to logon.php Nothing else needs to be done to protect any page. This is accomplished by simply placing at the top of each protected page: <?php session_start(); require(auth.php); Of course this requires the OP to place this code on each page he wants to protect, but that's a small price to pay for security and ease of implementation. The auth.php script only checks IF the user logged-in via a security variable. For example: if ($_SESSION['security'] != TRUE) { header('location:logon.php'); // redirect to login script. exit(); } // else user is permitted to pass If the user is logged in, then the user is permitted to travel to whatever scripts that contain the require(auth.php); statement. The login script in turn simply asks for the user ID and PASSWORD. If these are correct (via a db or file lookup), then the login script sets the security session variable to TRUE else it defaults to FALSE. Keep in mind that the only job of the login script is to set the security session variable to TRUE -- it is loosely coupled. Likewise, the authorization script is only concerned with the setting of the security session variable -- it is also loosely coupled. Both of these provide a good security solution. EOP (End of Problem). Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com |