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_VARS["REQUEST_URI"];
$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("Location:".$_CONF['site_url']"./registration.php");
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

re: Suggestion for handling pages requiring redirect using Config File

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("Location: ...");
exit();
}

(Not tested)

--
Oli

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.

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
http://OpenSkyWebDesign.com

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@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>