Suggestion for handling pages requiring redirect using Config File

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Greg Scharlemann

    #1

    Suggestion for handling pages requiring redirect using Config File

    I thought I had a workable approach to specifing which pages required a
    redirect in a config file, but it appears the way I'm attempting to do
    it is not going to work.

    The idea is that I can specify in the config file all of the pages that
    require a user to login otherwise the page will redirect if the user is
    not logged in.

    config.php looks like this:
    ----------------------
    // This allows you to set which pages require a login. If the
    // user tries to access a page specified below, they are
    // redirected to the specified page (usually the
    // registration page).

    // The # of pages that require user login
    $_CONF['required_login _pages'] = 1;
    $_CONF['required_login _0'] = '/myaccount.php'; //(slash required)
    ----------------------

    and header.php (which is included in every page) looks like this:
    ----------------------
    $url = $HTTP_SERVER_VA RS["REQUEST_UR I"];
    $numberPages = $_CONF['required_login _pages'];

    for($i = 0; $i < $numberPages; $i++) {
    print "page = " . $_CONF['required_login _$i'];
    if(beginsWith($ url, $_CONF['required_login _$i'])) {
    //header("Locatio n:".$_CONF['site_url']"./registration.ph p");
    print $_CONF['required_login _$i'];
    }
    }

    // returns true if $str begins with $sub
    function beginsWith( $str, $sub ) {
    return ( substr( $str, 0, strlen( $sub ) ) == $sub );
    }
    ---------------------

    The problem is php doesn't seem to like the $_CONF['required_login _$i']
    statement in the for loop. Anyone have a suggestion on another option
    for handling this?

    Thanks, Greg

  • Oli Filth

    #2
    Re: Suggestion for handling pages requiring redirect using ConfigFile

    Greg Scharlemann said the following on 12/11/2005 23:01:[color=blue]
    > I thought I had a workable approach to specifing which pages required a
    > redirect in a config file, but it appears the way I'm attempting to do
    > it is not going to work.
    >
    > The idea is that I can specify in the config file all of the pages that
    > require a user to login otherwise the page will redirect if the user is
    > not logged in.
    >
    > config.php looks like this:
    > ----------------------
    > // This allows you to set which pages require a login. If the
    > // user tries to access a page specified below, they are
    > // redirected to the specified page (usually the
    > // registration page).
    >
    > // The # of pages that require user login
    > $_CONF['required_login _pages'] = 1;
    > $_CONF['required_login _0'] = '/myaccount.php'; //(slash required)
    > ----------------------[/color]

    Urrgghh, nasty!
    Use nested arrays instead, i.e.:

    $_CONF['required_login '][0] = '/myaccount.php';
    $_CONF['required_login '][1] = '/other.php';
    $_CONF['required_login '][2] = '/another.php';
    ....

    That way, you don't even need $_CONF['required_login _pages'], as
    count($_CONF['required_login ']) will give the same effect.

    You could then reduce your test logic to:

    if (array_search($ _SERVER['PHP_SELF'], $_CONF['required_login ']))
    {
    header("Locatio n: ...");
    exit();
    }

    (Not tested)

    --
    Oli

    Comment

    • Chung Leong

      #3
      Re: Suggestion for handling pages requiring redirect using Config File

      Greg Scharlemann wrote:[color=blue]
      > I thought I had a workable approach to specifing which pages required a
      > redirect in a config file, but it appears the way I'm attempting to do
      > it is not going to work.
      >
      > The idea is that I can specify in the config file all of the pages that
      > require a user to login otherwise the page will redirect if the user is
      > not logged in.[/color]

      That's not an approach I'd favor for practical reason. While you're
      working in your config file, it's hard to remember exactly and fully
      which pages require login and which do not. Personally I prefer to let
      the page make the determination individually, as the context is clear
      while you're working in it.

      What I usually do is have a function like this:

      function RestrictAccess( ) {
      if(!GetUserID() ) {
      Redirect("login .php");
      }
      }

      And then call it on any page that isn't public. For an application with
      multi-level access, the function would take a parameter, indication
      what level is required.

      Comment

      • MsKitty

        #4
        Re: Suggestion for handling pages requiring redirect using Config File

        You need to use the eval statement in order to use a variable in a
        variable name, something like:
        eval("print \$_CONF['required_login _$i'];");

        But I agree with the other commenters. Let the page determine this. I
        usually put an include statement at the top of each file needing it.
        The included code checks if the session login variable is set and if
        not, uses a header statement to relocate to the login page.

        Kitty
        San Diego web design, development, training, and programming - we set up membership sites, Blogs, Ecommerce, Dynamic Content, and easily maintained web sites


        Comment

        • Peter Fox

          #5
          Re: Suggestion for handling pages requiring redirect using Config File

          Following on from Greg Scharlemann's message. . .[color=blue]
          >I thought I had a workable approach to specifing which pages required a
          >redirect in a config file, but it appears the way I'm attempting to do
          >it is not going to work.[/color]

          Bad approach in general. Horrible to maintain and as I understand your
          logic a page not in the list gets away scot-free and so fails unsafe.

          The better approach is to have a 'should I be here' function at the top
          of any page where you want any control over 'should I be here'.
          Obviously this goes into a single call of a function with all the other
          standard top of page stuff.

          You may notice the test is 'should I be here' not 'should we jump
          elsewhere' that is focussing on the reasons that drive the logic rather
          than the results. There are all sorts of reasons for jumping pages
          elsewhere:-
          * Not logged in
          * Insufficient permission
          * You have arrived at a record detail page without going through a
          'select record' screen.
          * You have arrived at a screen out of sequence where the sequence is
          important
          * News flash
          * You have finished an excursion (eg a generic pick a date screen called
          from anywhere) and want to return to where you left off.

          Also, and 'hey you must login first - here we go' is the classic
          example, you might be wanting to handle the situation in-line as far as
          your page logic is concerned. ie.
          o Test-Jump elsewhere-Continue
          o Test-Jump elsewhere (then come back here)-Continue.
          o Test-Set flags-Continue (constrained by flags)

          So for example in a menu we might test to see if the user has
          administrator's rights and if so switch on additional menu items.
          Although this doesn't involve a jump it is handy to be able to class it
          together with those sort of tests at the top of the page and then all
          that sort of stuff has been got out of the way and anyone coming to look
          at a the code can quickly grasp what it is about.

          I implement a HaveWeComeFrom function which takes a list of possible
          pages we might have just left as an argument (only where it is important
          of course) which if it fails goes back to a configured main menu page
          and 'can't do that there 'ere' message.

          I hope this ramble through checking logic illustrates why it's best to
          put the test parameters in the pages themselves.
          --
          PETER FOX Not the same since the bottom fell out of the bucket business
          peterfox@eminen t.demon.co.uk.n ot.this.bit.no. html
          2 Tees Close, Witham, Essex.
          Gravity beer in Essex <http://www.eminent.dem on.co.uk>

          Comment

          Working...