Should we use require_once instead header location?

Question

Hello commnunity, i have somthing like this: (if this page needs the user to be logged)

if(!isset($_SESSION['usr_id'])){          //if not a logged user
    $_SESSION['redir']=curPageURL();//Saving the current page for the redirection
    header('Location: ../Session/loginFrm.php'); 
}

and in loginFrm.php, we do:

{...after validation}    
if(isset($_SESSION['redir'])){
        header('Location: '.$_SESSION['redir']);
    }else{...}

in this page, they say we should use something like this instead:

 ...
    require_once '../Session/loginFrm.php';
    exit();

This doesn't work for me, the session variable now contains the included page, and not the current page.

What do you think about?

Answer 1

I would personally recommend against that. The reason is content to url mapping. If you allow the inclusion of the login page on any url, then how are search engines supposed to index content (or how are you to manage content since if you're handed a url, you get different output for different states).

URL stands for Uniform Resource Locator. It's meant to allow access to a resource. That's why (personally) I'd rather always have a 1:1 mapping between content and URL (and hence not have pages display different things based on non-URL/POST data)...

But that's just my $0.02...

Answer 2

He omits an important piece of information: resetting the execution context.

When you do a redirect, the new page loads and can assume it is the page requested. Most pages are written like that and most PHP programmers write pages like that. It also means you can control the context better through the redirect.

If you want to support that include() trick, then the page being included has to be written quite differently. It has to understand that it is now inheriting an execution context that may include rubbish from the calling file. It also means that the URL the user sees in their browser is not going to be the same every time. The included page/file must account for that when setting up POST targets (for instance) or you will get very bizarre errors.

The reasoning behind his recommendation is good, but you have to look at in a wider context: principally, how often will you need to issue the redirect (but also how slow is the upstream connection)? Since it looks like a login auto-redirect, my guess would be not all that often. People are used to redirects all the time, so yours is unlikely to stand out as excessive. So put this problem off until the redirect becomes a problem.