phplib-users

[Phplib-users] Mixing Authenticated & unauthenticated Pages

[T. R. <Te...@Te...>]

Thanks all for your help with my revalidation problems!  I'm very glad to be
beyond that, now I'm moving ahead and making new mistakes.  (the only way
real progress is ever made!)
I'm trying to mix authenticated & "anonymous/nobody" scripts.

I include() a menu in the left hand gutter of every page.  If you're logged
on with user permissions, you get one menu, admin - you get another.  If you
haven't logged on at all, you only see a log in form.  (pretty basic stuff)
Items across the top navigation bar of the page don't require
authentication.  To handle those pages, I created a second subclass of Auth
called defaultAuth that sets $nobody to true.

If I open a non-privileged page, like say contacts.php - the left-hand menu
disappears. OK - that makes sense, the defaultAuth is active and not my
customAuth class.  In a moment of misguided clarity, I added a page_open()
in the left navigation that uses my customAuth class.  Great!  Now I can see
the left hand menu when I'm on a page that uses defaultAuth.

Wait just a second boy-genius! - Now users who haven't logged on yet are
forced to log on when that left nav is executed during the include().
Ahhh, the law of unintended consequences bites me in the rump again!

Anyone got any tips they'd like to share for mixing authentication modes?

Thanks in advance,

Terry

Re: [Phplib-users] Mixing Authenticated & unauthenticated Pages

[Nathaniel P. <np...@te...>]

----- Original Message ----- 
From: "T. Riedel" <Te...@Te...>
To: <php...@li...>
Sent: Monday, August 18, 2003 8:07 AM
Subject: [Phplib-users] Mixing Authenticated & unauthenticated Pages


> I include() a menu in the left hand gutter of every page.  If you're
logged
> on with user permissions, you get one menu, admin - you get another.  If
you
> haven't logged on at all, you only see a log in form.  (pretty basic
stuff)
> Items across the top navigation bar of the page don't require
> authentication.  To handle those pages, I created a second subclass of
Auth
> called defaultAuth that sets $nobody to true.
>
> If I open a non-privileged page, like say contacts.php - the left-hand
menu
> disappears. OK - that makes sense, the defaultAuth is active and not my
> customAuth class.  In a moment of misguided clarity, I added a page_open()
> in the left navigation that uses my customAuth class.  Great!  Now I can
see
> the left hand menu when I'm on a page that uses defaultAuth.
>
> Wait just a second boy-genius! - Now users who haven't logged on yet are
> forced to log on when that left nav is executed during the include().
> Ahhh, the law of unintended consequences bites me in the rump again!
>
> Anyone got any tips they'd like to share for mixing authentication modes?

Uh... Don't do it? Especially not multiple times for the same page as it
seems you're doing from the description of the above (once in the included
menu and once on the actual page). That way lies madness. You should be able
to add default auth functionality to your existing customAuth class by
setting the class variable $nobody to true in local.inc. Then on any page
you don't want to allow the 'default' authentication to take effect, use
$auth->login_if($auth->auth['uid'] == 'nobody') right after the page_open()
to force a login (the easy way) or use $perm->check("user") (or whatever
your desired permission setting is) and then modify your perminvalid.ihtml
file to always include a relogin link for any user with the UID of "nobody"
(probably more accesible as it allows one to remain "authenticated" as
nobody). See the documentation on default auth for more details:
<http://www.sanisoft.com/phplib/manual/authAddedInfo.php>

I'd say what you should do is use $perm->has_perm() on the included menu
script to detect the permission settings of the user, but leave it up to
each individual page to do the page_open() and page_close() calls (you can
also use the auto_prepend_file and auto_append_file settings in php.ini, or
inside the apache configuration, to do this for you if you use PHPlib
consistantly throughout your site). If you use your menu on pages that don't
use PHPlib (or at least those that don't instanciate $perm) as well, first
detect whether or not $perm is an object (using is_object()), then act
accordingly.

Hope that helps. If I've completely missed the mark, let me know.

Full disclosure: I haven't used default auth much, so I don't know all the
ins-and-outs. So, to anyone on the list, If I'm wrong about something,
please let me know.

_________________________________
Nathaniel Price
Webmaster <http://www.tesseract.net>

RE: [Phplib-users] Mixing Authenticated & unauthenticated Pages

[T. R. <Te...@Te...>]

Thanks again Nathaniel - I've taken your advice and gotten a little further,
but I'm not quite there yet.

- I decided to "stop the madness" and yanked those embedded page_open/close
calls from my menu code
- I also modified my menu to test is_object($perm) before trying to render
my navigation bar - very good, common sense suggestion!
- I'm already doing an autoprepend to load a prepend script that includes
all the page/sess/local/yada-yada-yada

Perhaps I'm just a complete dolt, but the manual doesn't seem very clear to
me.  It makes it seem that you need to create an Auth subclass that and set
$nobody to true.  Just flipping the nobody flag to true in my MyCustomAuth
doesn't seem right.  When does the class force authentication and when does
it just cruise along as nobody?

The login_if() FORCES a login if you're nobody!  So it's perfect if you want
to force users to reauthenticate.  In this case, I'm trying to avoid
annoying requests to reauthenticate.  If you've logged on once, and then
decided to click a "no-permissions-required" script, I don't want the $auth
object stomped by a $nobody=true version which will forced the user to
reauthenticate when he returns to a secured page.  (did that make sense?)

I guess what I really want to do is allow a user to have TWO instances of an
Auth class - a "normal" version that requires login and a "nobody" auth
class to browse unsecured pages.  It seems rather strange, but from my
confused point of view - it seems to make sense.  ...probably just
succumbing to the madness again....

-----Original Message-----
From: Nathaniel Price [mailto:np...@te...]
Sent: Monday, August 18, 2003 1:14 PM
To: T. Riedel; php...@li...
Subject: Re: [Phplib-users] Mixing Authenticated & unauthenticated Pages

<<<snip>>>

Uh... Don't do it? Especially not multiple times for the same page as it
seems you're doing from the description of the above (once in the included
menu and once on the actual page). That way lies madness. You should be able
to add default auth functionality to your existing customAuth class by
setting the class variable $nobody to true in local.inc. Then on any page
you don't want to allow the 'default' authentication to take effect, use
$auth->login_if($auth->auth['uid'] == 'nobody') right after the page_open()
to force a login (the easy way) or use $perm->check("user") (or whatever
your desired permission setting is) and then modify your perminvalid.ihtml
file to always include a relogin link for any user with the UID of "nobody"
(probably more accesible as it allows one to remain "authenticated" as
nobody). See the documentation on default auth for more details:
<http://www.sanisoft.com/phplib/manual/authAddedInfo.php>

I'd say what you should do is use $perm->has_perm() on the included menu
script to detect the permission settings of the user, but leave it up to
each individual page to do the page_open() and page_close() calls (you can
also use the auto_prepend_file and auto_append_file settings in php.ini, or
inside the apache configuration, to do this for you if you use PHPlib
consistantly throughout your site). If you use your menu on pages that don't
use PHPlib (or at least those that don't instanciate $perm) as well, first
detect whether or not $perm is an object (using is_object()), then act
accordingly.

Hope that helps. If I've completely missed the mark, let me know.

Full disclosure: I haven't used default auth much, so I don't know all the
ins-and-outs. So, to anyone on the list, If I'm wrong about something,
please let me know.

_________________________________
Nathaniel Price
Webmaster <http://www.tesseract.net>

Re: [Phplib-users] Mixing Authenticated & unauthenticated Pages

[Nathaniel P. <np...@te...>]

----- Original Message ----- 
From: "T. Riedel" <Te...@Te...>
To: "'Nathaniel Price'" <np...@te...>;
<php...@li...>
Sent: Monday, August 18, 2003 11:54 AM
Subject: RE: [Phplib-users] Mixing Authenticated & unauthenticated Pages


[snip]
> Perhaps I'm just a complete dolt, but the manual doesn't seem very clear
to
> me.  It makes it seem that you need to create an Auth subclass that and
set
> $nobody to true.  Just flipping the nobody flag to true in my MyCustomAuth
> doesn't seem right.  When does the class force authentication and when
does
> it just cruise along as nobody?

From the documentation:
|To use default authentication, create a subclass of My_Auth as shown above
|with the nobody flag set (Note: No need to extend in two steps. The only
|important thing here is that the nobody flag is set.)

In other words, you can just set the $nobody flag to true.

Default auth forces authentication only when the value passed to login_if()
evaluates to true. That means that on a page where you want default auth
functioning and allow some content to be viewed by "nobody", you will need
to provide a link on the page that sets a variable within PHP and pass that
variable to login_if(), as per the documentation.

> The login_if() FORCES a login if you're nobody!  So it's perfect if you
want
> to force users to reauthenticate.  In this case, I'm trying to avoid
> annoying requests to reauthenticate.  If you've logged on once, and then
> decided to click a "no-permissions-required" script, I don't want the
$auth
> object stomped by a $nobody=true version which will forced the user to
> reauthenticate when he returns to a secured page.  (did that make sense?)

It does, but you're confusing two things (which I think is in part due to a
particularly confusing naming convention). The $nobody flag merely tells
Auth that we are in Default Authentication mode. In other words, if the user
is not logged in, Auth will automatically log them in as "nobody". It
doesn't mean that you're /always/ "nobody". It just tells Auth what to do if
it can't authenticate normally. A logged in user will retain their login
even when visiting a default auth page.

There's also the $auth->auth['uid'] == "nobody" setting. /This/ is what the
Auth class uses to determine if the user is "nobody", and it will be
overwritten by the normal data for a logged-in user once they're logged in.
Auth will never overwrite this data unless the user is logged out and then
revisits a default auth page.

The example that I provided of using login_if($auth->auth['uid']=="nobody")
was meant as an example of what you could do to simulate the behavior of a
normal page (without default authentication) while in Default Authentication
mode. In other words a user that hasn't logged in, but is "authenticated" as
"nobody" will always see a login screen. If this isn't what you want, then
by all means, do something else. :)

> I guess what I really want to do is allow a user to have TWO instances of
an
> Auth class - a "normal" version that requires login and a "nobody" auth
> class to browse unsecured pages.  It seems rather strange, but from my
> confused point of view - it seems to make sense.  ...probably just
> succumbing to the madness again....

As I said above, a single class will handle both types of uses... that's why
default auth was created in the first place. Anyway, I understand the
confusion. PHPlib isn't the best documented project in the world (although
it's a /lot/ better now than when I started out with it), or the easiest to
understand, but once I figured out how it works I realized just how
powerful/useful it is for doing what it does.

Also, I've found a flowchart that helped me wrap my head around the whole
authentication process in PHPlib here:
<http://www.drostan.org/Application/webdev/uod/auth_phplib.php>

Hope that helps!

_________________________________
Nathaniel Price
Webmaster <http://www.tesseract.net>