phplib-users — A list for users of phplib to talk / discuss phplib

RE: [Phplib-users] Session/Auth Problem

[Rob H. <rob...@ws...>]

I am trying out the "complete" snapshot with Gian and then I will do exactly
that.  I can sent a couple of pages that recreates the "features" ;-)

Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: Marko Kaening [mailto:M.K...@os...]
> Sent: Thursday, October 10, 2002 10:12 AM
> To: Rob Hutton
> Cc: phplib-users list
> Subject: RE: [Phplib-users] Session/Auth Problem
>
>
> Hi Rob,
>
> I don't know whether i can help... since for me everything works just
> right. Don't really understand why it doesn't in your case...
>
> > window.refresh.  I am not picking up the $sess and $auth
> variables on the
> > out page once auth has occured.  The session cookie changes, and the IDs
> Well, I didn't use IFRAME, yet, but I suspect there is no difference to
> FRAME. Hmmm, I do the initial auth inside the parent frame and then the
> application starts to run in 2 frames, where only one (main window) uses
> page_close(). The other frame I use as a menu frame and there I can avoid
> the page_close(). If I need to update some data of the session I simply
> call another script (also with redirection).
>
> > match the on the outer and inner pages, but the $sess and $auth
> variables
> > are only available to the inner page..
> That sounds strange, but I am afraid I had such a situation also
> sometimes. I got in both frames login screens everytime... But now it
> works.
>
> Perhaps you could strip your application down to short examplary code
> which demonstrates the behaviour.
>
> Marko

RE: [Phplib-users] Session/Auth Problem

[Marko K. <M.K...@os...>]

Hi Rob,

I don't know whether i can help... since for me everything works just
right. Don't really understand why it doesn't in your case...

> window.refresh.  I am not picking up the $sess and $auth variables on the
> out page once auth has occured.  The session cookie changes, and the IDs
Well, I didn't use IFRAME, yet, but I suspect there is no difference to
FRAME. Hmmm, I do the initial auth inside the parent frame and then the
application starts to run in 2 frames, where only one (main window) uses
page_close(). The other frame I use as a menu frame and there I can avoid
the page_close(). If I need to update some data of the session I simply
call another script (also with redirection).

> match the on the outer and inner pages, but the $sess and $auth variables
> are only available to the inner page..
That sounds strange, but I am afraid I had such a situation also
sometimes. I got in both frames login screens everytime... But now it
works.

Perhaps you could strip your application down to short examplary code
which demonstrates the behaviour.

Marko

RE: [Phplib-users] Session/Auth Problem

[Rob H. <rob...@ws...>]

  Thank you for the voice of reason here.  Maybe you can help in this
conversation.  I have a page with an IFRAME in it in which auth (and other
things) happen.  Once something has happened within the iframe, it does a
window.refresh.  I am not picking up the $sess and $auth variables on the
out page once auth has occured.  The session cookie changes, and the IDs
match the on the outer and inner pages, but the $sess and $auth variables
are only available to the inner page..

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

View our Symantec Client Security Demo:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271

Download the Symantec Client Security Fact Sheet:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271

Download the Symantec Client Security Brochure:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Marko
> Kaening
> Sent: Thursday, October 10, 2002 3:21 AM
> To: phplib-users list
> Subject: Re: [Phplib-users] Session/Auth Problem
>
>
> > That can work if you never write the session variables back out at the
> > end of that page.
> I do work with frames and sessions and never had severe problems. Maybe
> it's sometimes a bit tricky to update frames... But this can be solved by
> redirects, at least I see no other way.
> The main thing, as you say, is to have only in ONE frame the page_close()
> call, otherwise there will be problems. If many frames use page_open()
> it's okay!
>
> So you don't need to forget about frames at all if you mind this!
>
> Marko
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re: [Phplib-users] Session/Auth Problem

[Marko K. <M.K...@os...>]

> That can work if you never write the session variables back out at the
> end of that page.
I do work with frames and sessions and never had severe problems. Maybe
it's sometimes a bit tricky to update frames... But this can be solved by
redirects, at least I see no other way.
The main thing, as you say, is to have only in ONE frame the page_close()
call, otherwise there will be problems. If many frames use page_open()
it's okay!

So you don't need to forget about frames at all if you mind this!

Marko

Re: [Phplib-users] Network username

[Chris J. <ch...@ch...>]

On Wed, Oct 09, 2002 at 01:20:35PM -0400, Poduje, Miguel         (LanInfo) wrote:
> I have my webserver in a Solaris enviroment... But my users come from a
> Windows NT network...
> How can i get the IP addres and username to put it in php variables?
> thanks

For most users, the IP address (perhaps of an intermediate caching or firewall
proxy, not the actual user's workstation) is available from PHP via the
$_SERVER['REMOTE_ADDR'] variable.

Which username are you referring to?  If you are using HTTP basic
authentication, the username would be in $_SERVER['PHP_AUTH_USER'] .  Or are
you talking about using the Auth class in PHPLIB?  In that case,
$auth->auth['uname'] would be a good bet.

-- 
    ..chris

RE: [Phplib-users] handle perm in auth

[Rob H. <rob...@ws...>]

I think you are trying to fit a square peg in a round hole.  That kind of
bitwise math is too complex to reasonably maintain for the average db admin.
IMHO it would be better to have a user_perms table like:

uid
permname
permlevel

Then it would be easy to see in the db what perms are set and still fits in
with the current scheme.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

View our Symantec Client Security Demo:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271

Download the Symantec Client Security Fact Sheet:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271

Download the Symantec Client Security Brochure:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Wednesday, October 09, 2002 9:36 PM
> To: phplib-users
> Subject: Re: [Phplib-users] handle perm in auth
>
>
> Il 02:44, giovedì 10 ottobre 2002, Rob Hutton ha scritto:
> > It's tied to the user, not the page.  So I can't be an author
> of one page
> > and a reviewer of another page.
>
> But why not? That is only a data mask. You need only to design
> and combine
> some values..
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

Re: [Phplib-users] handle perm in auth

[Giancarlo <gia...@na...>]

Il 02:44, gioved=EC 10 ottobre 2002, Rob Hutton ha scritto:
> It's tied to the user, not the page.  So I can't be an author of one pa=
ge
> and a reviewer of another page.

But why not? That is only a data mask. You need only to design and combin=
e=20
some values..

RE: [Phplib-users] handle perm in auth

[Rob H. <rob...@ws...>]

It's tied to the user, not the page.  So I can't be an author of one page
and a reviewer of another page.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

View our Symantec Client Security Demo:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271

Download the Symantec Client Security Fact Sheet:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271

Download the Symantec Client Security Brochure:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271


> -----Original Message-----
> From: Daniel Bondurant [mailto:bo...@io...]
> Sent: Wednesday, October 09, 2002 8:16 PM
> To: rob...@ws...
> Cc: phplib-users
> Subject: RE: [Phplib-users] handle perm in auth
>
>
> what is wrong with $perm->have_perm() on your page?
> http://www.sanisoft.com/phplib/manual/permissionsMethods.php
>
>
> On Wed, 2002-10-09 at 17:18, Rob Hutton wrote:
> > WARNING FEATURE REQUEST  FEATURE REQUEST!!!!!!
> >
> > Gian,
> >   I have seen several apps lately (especially content
> management apps) that
> > require different perms per page.  I was going to suggest a
> perm extension
> > something like page_open('perms' => 'perPagePerms('identifier'));  that
> > would set permissions on a per page or module or whatever
> basis.  Can you
> > have that done by tomarrow? ;-)
> >
> > Rob Hutton
> > Web Safe
> > www.wsafe.com
> >
> > **********************************************************************
> >
> > Introducing Symantec Client Security - Integrated Anti-Virus,
> > Firewall, and Intrusion Detection for the Client.
> >
> > Learn more:
> > http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271
> >
> > View our Symantec Client Security Demo:
> > http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271
> >
> > Download the Symantec Client Security Fact Sheet:
> > http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271
> >
> > Download the Symantec Client Security Brochure:
> > http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271
> >
> >
> > > -----Original Message-----
> > > From: php...@li...
> > > [mailto:php...@li...]On Behalf Of
> Giancarlo
> > > Sent: Wednesday, October 09, 2002 7:42 PM
> > > To: phplib-users
> > > Subject: [Phplib-users] handle perm in auth
> > >
> > >
> > > you know, the perm stuff was added later to phplib. And there are
> > > in fatc two
> > > ways of working with phplib: auth check is dome at the obj start,
> > > perm has to
> > > be checked in the page eventually. auth is start-checked,
> perm has to be
> > > post-checked.
> > >
> > > So imagine the possibility of handling perm->has_the_moon within your
> > > extended auth class methods... It is an alternative anyway,
> > > something that
> > > with the new design becomes possible.
> > >
> > > I propose you these two pieces, one of the actual page.inc
> > > (snapshot), and
> > > the other of  tomorrow's. There is infact no difference in the
> > > flow, just a
> > > lot of development doors open, eg by extending the lifetime
> > > concept from an
> > > unique general value, to something related to the permissions.
> > > Ofcourse, we could also add a new $perm->check_expire
> functionality, and
> > > place it everywhere needed, but...the auth[exp] is broken logic
> > > also, because
> > > it doesn't tell us the expire that was calculated on, and this
> > > new snapshot
> > > coming out is ready for this new fubctionality.
> > >
> > > With this I think the circle is really closed, and I am surprised
> > > myself how
> > > many things went right and how this all in fact changes nothing
> > > in the usual
> > > usage.
> > >
> > > Maybe an interesting discussion.
> > >
> > > Will work on this, thanks all
> > >
> > > Gian
> > >
> > >
> > >
> > > <snip>
> > > I attach you a page inc that perfectly works with the latest snapshot.
> > >
> > > The revolution is that the perm object can be started before the
> > > auth object
> > > is started, even though after it has been instantiated.
> > > This is perfectly functional, an allows further, optional,
> > > development and
> > > usage
> > > I attach a commented version of a part of it. I'd wait for this,
> > > although it
> > > has no practical differences but just opens doors.
> > >
> > > I hope I am not getting a crab with this..
> > >
> > >
> > > ----------old (snapshot) page.inc--------------------------------
> > >     # the auth feature depends on sess
> > >     if (isset($feature["auth"])) {
> > >       global $auth;
> > >
> > >       if (!is_object($auth)) {
> > >         $auth = new $feature["auth"];
> > >       }
> > >       $auth->start();
> > >       ####################################################
> > >       ## start does not rely on the perm obj anyway
> > >       ## start does not set any of his auth[perm] values, except,
> > >       ## if not authed, start() will clear his auth[perm],
> > > splash and exit
> > >       ## this is the only action of auth on its own auth[perm]
> > >       ####################################################
> > >       # the perm feature depends on auth and sess
> > >       if (isset($feature["perm"])) {
> > >         global $perm;
> > >
> > >         if (!is_object($perm)) {
> > >           $perm = new $feature["perm"];
> > >         }
> > >       }
> > >
> > >       # the user feature depends on auth and sess
> > >       ...
> > >
> > > ---------new page.inc------------------------------------------------
> > >
> > >     # the auth feature depends on sess
> > >     if (isset($feature["auth"])) {
> > >       global $auth;
> > >       if (is_object($auth))
> > >          $auth= $auth->check_feature($feature["auth"]);
> > >       else
> > >          $auth = new $feature["auth"];
> > >
> > >       #########################################
> > >       # the perm object is started if requested
> > >       #########################################
> > >       # the perm feature depends on auth and sess
> > >       if (isset($feature["perm"])) {
> > >         global $perm;
> > >
> > >         if (!is_object($perm)) {
> > >           $perm = new $feature["perm"];
> > >         }
> > >       }
> > >
> > >       ####################################################
> > >       ## start does not rely on the perm obj
> > >       ## start does not set anyof his auth[perm] values, except,
> > >       ## if not authed, start() will clear his auth[perm],
> > > splash and exit
> > >       ## this is the only action of auth on its own auth[perm]
> > >       ####################################################
> > >       ## ***** BUT WE CAN CHECK STUFF FROM PERM,
> > >       ## eg assign different auth->lifetime for different
> perms  ******
> > >       ## ***** in is_authenticated/check_expire
> > >       ########################################################
> > >
> > >       if (!$auth->start() ) {  ### user is not authenticated, nobody
> > >          if (!$auth->nobody) { ### page cannot be seen by
> > > unauthed users
> > >             page_showform();    ### splash the form
> > >             $sess->freeze();    ### save state
> > >             exit;
> > >           }
> > >       }
> > >
> > >       # the user feature depends on auth and sess
> > >       ...
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Phplib-users mailing list
> > > Php...@li...
> > > https://lists.sourceforge.net/lists/listinfo/phplib-users
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

RE: [Phplib-users] handle perm in auth

[Daniel B. <bo...@io...>]

what is wrong with $perm->have_perm() on your page?
http://www.sanisoft.com/phplib/manual/permissionsMethods.php


On Wed, 2002-10-09 at 17:18, Rob Hutton wrote:
> WARNING FEATURE REQUEST  FEATURE REQUEST!!!!!!
> 
> Gian,
>   I have seen several apps lately (especially content management apps) that
> require different perms per page.  I was going to suggest a perm extension
> something like page_open('perms' => 'perPagePerms('identifier'));  that
> would set permissions on a per page or module or whatever basis.  Can you
> have that done by tomarrow? ;-)
> 
> Rob Hutton
> Web Safe
> www.wsafe.com
> 
> **********************************************************************
> 
> Introducing Symantec Client Security - Integrated Anti-Virus,
> Firewall, and Intrusion Detection for the Client.
> 
> Learn more:
> http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271
> 
> View our Symantec Client Security Demo:
> http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271
> 
> Download the Symantec Client Security Fact Sheet:
> http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271
> 
> Download the Symantec Client Security Brochure:
> http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271
> 
> 
> > -----Original Message-----
> > From: php...@li...
> > [mailto:php...@li...]On Behalf Of Giancarlo
> > Sent: Wednesday, October 09, 2002 7:42 PM
> > To: phplib-users
> > Subject: [Phplib-users] handle perm in auth
> >
> >
> > you know, the perm stuff was added later to phplib. And there are
> > in fatc two
> > ways of working with phplib: auth check is dome at the obj start,
> > perm has to
> > be checked in the page eventually. auth is start-checked, perm has to be
> > post-checked.
> >
> > So imagine the possibility of handling perm->has_the_moon within your
> > extended auth class methods... It is an alternative anyway,
> > something that
> > with the new design becomes possible.
> >
> > I propose you these two pieces, one of the actual page.inc
> > (snapshot), and
> > the other of  tomorrow's. There is infact no difference in the
> > flow, just a
> > lot of development doors open, eg by extending the lifetime
> > concept from an
> > unique general value, to something related to the permissions.
> > Ofcourse, we could also add a new $perm->check_expire functionality, and
> > place it everywhere needed, but...the auth[exp] is broken logic
> > also, because
> > it doesn't tell us the expire that was calculated on, and this
> > new snapshot
> > coming out is ready for this new fubctionality.
> >
> > With this I think the circle is really closed, and I am surprised
> > myself how
> > many things went right and how this all in fact changes nothing
> > in the usual
> > usage.
> >
> > Maybe an interesting discussion.
> >
> > Will work on this, thanks all
> >
> > Gian
> >
> >
> >
> > <snip>
> > I attach you a page inc that perfectly works with the latest snapshot.
> >
> > The revolution is that the perm object can be started before the
> > auth object
> > is started, even though after it has been instantiated.
> > This is perfectly functional, an allows further, optional,
> > development and
> > usage
> > I attach a commented version of a part of it. I'd wait for this,
> > although it
> > has no practical differences but just opens doors.
> >
> > I hope I am not getting a crab with this..
> >
> >
> > ----------old (snapshot) page.inc--------------------------------
> >     # the auth feature depends on sess
> >     if (isset($feature["auth"])) {
> >       global $auth;
> >
> >       if (!is_object($auth)) {
> >         $auth = new $feature["auth"];
> >       }
> >       $auth->start();
> >       ####################################################
> >       ## start does not rely on the perm obj anyway
> >       ## start does not set any of his auth[perm] values, except,
> >       ## if not authed, start() will clear his auth[perm],
> > splash and exit
> >       ## this is the only action of auth on its own auth[perm]
> >       ####################################################
> >       # the perm feature depends on auth and sess
> >       if (isset($feature["perm"])) {
> >         global $perm;
> >
> >         if (!is_object($perm)) {
> >           $perm = new $feature["perm"];
> >         }
> >       }
> >
> >       # the user feature depends on auth and sess
> >       ...
> >
> > ---------new page.inc------------------------------------------------
> >
> >     # the auth feature depends on sess
> >     if (isset($feature["auth"])) {
> >       global $auth;
> >       if (is_object($auth))
> >          $auth= $auth->check_feature($feature["auth"]);
> >       else
> >          $auth = new $feature["auth"];
> >
> >       #########################################
> >       # the perm object is started if requested
> >       #########################################
> >       # the perm feature depends on auth and sess
> >       if (isset($feature["perm"])) {
> >         global $perm;
> >
> >         if (!is_object($perm)) {
> >           $perm = new $feature["perm"];
> >         }
> >       }
> >
> >       ####################################################
> >       ## start does not rely on the perm obj
> >       ## start does not set anyof his auth[perm] values, except,
> >       ## if not authed, start() will clear his auth[perm],
> > splash and exit
> >       ## this is the only action of auth on its own auth[perm]
> >       ####################################################
> >       ## ***** BUT WE CAN CHECK STUFF FROM PERM,
> >       ## eg assign different auth->lifetime for different perms  ******
> >       ## ***** in is_authenticated/check_expire
> >       ########################################################
> >
> >       if (!$auth->start() ) {  ### user is not authenticated, nobody
> >          if (!$auth->nobody) { ### page cannot be seen by
> > unauthed users
> >             page_showform();    ### splash the form
> >             $sess->freeze();    ### save state
> >             exit;
> >           }
> >       }
> >
> >       # the user feature depends on auth and sess
> >       ...
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Phplib-users mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phplib-users
> >
> >
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

RE: [Phplib-users] handle perm in auth

[Rob H. <rob...@ws...>]

WARNING FEATURE REQUEST  FEATURE REQUEST!!!!!!

Gian,
  I have seen several apps lately (especially content management apps) that
require different perms per page.  I was going to suggest a perm extension
something like page_open('perms' => 'perPagePerms('identifier'));  that
would set permissions on a per page or module or whatever basis.  Can you
have that done by tomarrow? ;-)

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

View our Symantec Client Security Demo:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271

Download the Symantec Client Security Fact Sheet:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271

Download the Symantec Client Security Brochure:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Wednesday, October 09, 2002 7:42 PM
> To: phplib-users
> Subject: [Phplib-users] handle perm in auth
>
>
> you know, the perm stuff was added later to phplib. And there are
> in fatc two
> ways of working with phplib: auth check is dome at the obj start,
> perm has to
> be checked in the page eventually. auth is start-checked, perm has to be
> post-checked.
>
> So imagine the possibility of handling perm->has_the_moon within your
> extended auth class methods... It is an alternative anyway,
> something that
> with the new design becomes possible.
>
> I propose you these two pieces, one of the actual page.inc
> (snapshot), and
> the other of  tomorrow's. There is infact no difference in the
> flow, just a
> lot of development doors open, eg by extending the lifetime
> concept from an
> unique general value, to something related to the permissions.
> Ofcourse, we could also add a new $perm->check_expire functionality, and
> place it everywhere needed, but...the auth[exp] is broken logic
> also, because
> it doesn't tell us the expire that was calculated on, and this
> new snapshot
> coming out is ready for this new fubctionality.
>
> With this I think the circle is really closed, and I am surprised
> myself how
> many things went right and how this all in fact changes nothing
> in the usual
> usage.
>
> Maybe an interesting discussion.
>
> Will work on this, thanks all
>
> Gian
>
>
>
> <snip>
> I attach you a page inc that perfectly works with the latest snapshot.
>
> The revolution is that the perm object can be started before the
> auth object
> is started, even though after it has been instantiated.
> This is perfectly functional, an allows further, optional,
> development and
> usage
> I attach a commented version of a part of it. I'd wait for this,
> although it
> has no practical differences but just opens doors.
>
> I hope I am not getting a crab with this..
>
>
> ----------old (snapshot) page.inc--------------------------------
>     # the auth feature depends on sess
>     if (isset($feature["auth"])) {
>       global $auth;
>
>       if (!is_object($auth)) {
>         $auth = new $feature["auth"];
>       }
>       $auth->start();
>       ####################################################
>       ## start does not rely on the perm obj anyway
>       ## start does not set any of his auth[perm] values, except,
>       ## if not authed, start() will clear his auth[perm],
> splash and exit
>       ## this is the only action of auth on its own auth[perm]
>       ####################################################
>       # the perm feature depends on auth and sess
>       if (isset($feature["perm"])) {
>         global $perm;
>
>         if (!is_object($perm)) {
>           $perm = new $feature["perm"];
>         }
>       }
>
>       # the user feature depends on auth and sess
>       ...
>
> ---------new page.inc------------------------------------------------
>
>     # the auth feature depends on sess
>     if (isset($feature["auth"])) {
>       global $auth;
>       if (is_object($auth))
>          $auth= $auth->check_feature($feature["auth"]);
>       else
>          $auth = new $feature["auth"];
>
>       #########################################
>       # the perm object is started if requested
>       #########################################
>       # the perm feature depends on auth and sess
>       if (isset($feature["perm"])) {
>         global $perm;
>
>         if (!is_object($perm)) {
>           $perm = new $feature["perm"];
>         }
>       }
>
>       ####################################################
>       ## start does not rely on the perm obj
>       ## start does not set anyof his auth[perm] values, except,
>       ## if not authed, start() will clear his auth[perm],
> splash and exit
>       ## this is the only action of auth on its own auth[perm]
>       ####################################################
>       ## ***** BUT WE CAN CHECK STUFF FROM PERM,
>       ## eg assign different auth->lifetime for different perms  ******
>       ## ***** in is_authenticated/check_expire
>       ########################################################
>
>       if (!$auth->start() ) {  ### user is not authenticated, nobody
>          if (!$auth->nobody) { ### page cannot be seen by
> unauthed users
>             page_showform();    ### splash the form
>             $sess->freeze();    ### save state
>             exit;
>           }
>       }
>
>       # the user feature depends on auth and sess
>       ...
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

[Phplib-users] handle perm in auth

[Giancarlo <gia...@na...>]

you know, the perm stuff was added later to phplib. And there are in fatc two 
ways of working with phplib: auth check is dome at the obj start, perm has to 
be checked in the page eventually. auth is start-checked, perm has to be 
post-checked.

So imagine the possibility of handling perm->has_the_moon within your 
extended auth class methods... It is an alternative anyway, something that 
with the new design becomes possible.

I propose you these two pieces, one of the actual page.inc (snapshot), and 
the other of  tomorrow's. There is infact no difference in the flow, just a 
lot of development doors open, eg by extending the lifetime concept from an 
unique general value, to something related to the permissions.
Ofcourse, we could also add a new $perm->check_expire functionality, and 
place it everywhere needed, but...the auth[exp] is broken logic also, because 
it doesn't tell us the expire that was calculated on, and this new snapshot 
coming out is ready for this new fubctionality.

With this I think the circle is really closed, and I am surprised myself how 
many things went right and how this all in fact changes nothing in the usual 
usage.

Maybe an interesting discussion.

Will work on this, thanks all

Gian  



<snip>
I attach you a page inc that perfectly works with the latest snapshot.

The revolution is that the perm object can be started before the auth object 
is started, even though after it has been instantiated.
This is perfectly functional, an allows further, optional, development and 
usage
I attach a commented version of a part of it. I'd wait for this, although it 
has no practical differences but just opens doors.

I hope I am not getting a crab with this..


----------old (snapshot) page.inc--------------------------------
    # the auth feature depends on sess
    if (isset($feature["auth"])) {
      global $auth;
      
      if (!is_object($auth)) {
        $auth = new $feature["auth"];
      }
      $auth->start();   
      ####################################################
      ## start does not rely on the perm obj anyway
      ## start does not set any of his auth[perm] values, except,
      ## if not authed, start() will clear his auth[perm],  splash and exit
      ## this is the only action of auth on its own auth[perm]
      ####################################################
      # the perm feature depends on auth and sess
      if (isset($feature["perm"])) {
        global $perm;
        
        if (!is_object($perm)) {
          $perm = new $feature["perm"];
        }
      }

      # the user feature depends on auth and sess
      ...

---------new page.inc------------------------------------------------

    # the auth feature depends on sess
    if (isset($feature["auth"])) {
      global $auth;
      if (is_object($auth))
         $auth= $auth->check_feature($feature["auth"]);
      else
         $auth = new $feature["auth"];

      #########################################
      # the perm object is started if requested
      #########################################
      # the perm feature depends on auth and sess
      if (isset($feature["perm"])) {
        global $perm;
        
        if (!is_object($perm)) {
          $perm = new $feature["perm"];
        }
      }

      ####################################################
      ## start does not rely on the perm obj
      ## start does not set anyof his auth[perm] values, except,
      ## if not authed, start() will clear his auth[perm],  splash and exit
      ## this is the only action of auth on its own auth[perm]
      ####################################################
      ## ***** BUT WE CAN CHECK STUFF FROM PERM, 
      ## eg assign different auth->lifetime for different perms  ******
      ## ***** in is_authenticated/check_expire
      ########################################################

      if (!$auth->start() ) {  ### user is not authenticated, nobody 
         if (!$auth->nobody) { ### page cannot be seen by unauthed users      
            page_showform();    ### splash the form
            $sess->freeze();    ### save state
            exit;              
          }
      }

      # the user feature depends on auth and sess
      ...

Re: [Phplib-users] Session/Auth Problem

[Michael C. <mdc...@mi...>]

On Wed, Oct 09, 2002 at 05:31:34PM -0400, Rob Hutton wrote:
>   The iframe is a requirement of the site design as the top side menu areas
> must be available no matter where on the page the person is browsing.

So it boils down to poor design.  You can accomplish the same thing with
Javascript, not sure why you'd want to.  Most sites that do stuff like
that don't have to worry about me coming back.

>   Secondly, I understand the danger of having session variables overwrite
> each other, and in fact the outer frame will never need to make changes,
> just understand the session context, which it is currently not doing at the
> php-lib level although I have no problems calling the php session functions
> directly as once I am authenticated I get the correct SID and variables.

That can work if you never write the session variables back out at the
end of that page.

>   In fact, IFRAMES were created in response to the desire to be able to
> place scrolling content that is changeable inside another document without
> having to refresh the whole document, which is what I am trying to do with
> it.  The "correct method" depends completely on the design requirements and
> not an arbitrary opinion.

My "arbitrary opinion" is substantiated fact.  Search Google, there are
plenty of other people who can tell you the same thing.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

RE: [Phplib-users] Session/Auth Problem

[Rob H. <rob...@ws...>]

  The iframe is a requirement of the site design as the top side menu areas
must be available no matter where on the page the person is browsing.
  Secondly, I understand the danger of having session variables overwrite
each other, and in fact the outer frame will never need to make changes,
just understand the session context, which it is currently not doing at the
php-lib level although I have no problems calling the php session functions
directly as once I am authenticated I get the correct SID and variables.
  In fact, IFRAMES were created in response to the desire to be able to
place scrolling content that is changeable inside another document without
having to refresh the whole document, which is what I am trying to do with
it.  The "correct method" depends completely on the design requirements and
not an arbitrary opinion.

Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Michael
> Chaney
> Sent: Wednesday, October 09, 2002 5:15 PM
> To: php...@li...
> Subject: Re: [Phplib-users] Session/Auth Problem
>
>
> On Wed, Oct 09, 2002 at 08:56:55AM -0400, Rob Hutton wrote:
> > I have auth occurring inside a iframe on my page.  That works
> correctly and
> > that iframe has access to the $sess and $auth variables.  The
> outer frame
> > however does not.  Once I refresh it, the
> $GLOBALS['Site_Custom_Session']
> > variable gives me the same session ID, but $auth and $sess are
> not defined
> > in the outer frame.  Yes, the outer frame does a page_open (in fact, I
> > copied and pasted it from the inner frame just to make sure.
> >
> > Any Ideas?
>
> Yes.  Don't use frames.
>
> The purpose of the iframe is to allow you to include a bit of HTML from
> another site over which you have no control into your current page.
> More specifically, they were created to allow fancier banner ads to be
> created, html instead of gif's.
>
> What you're doing will always cause problems.  Please don't fool
> yourself into thinking that it's possible to do.  The inner and outer
> frame may well load somewhat simultaneously, meaning that two different
> pages may open your session variables, and subsequently save them back
> out.  It's quite possible in that case that changes to session variables
> may be lost.  The result will be flakey behavior, such as you've
> described.
>
> The correct method is to simply include the code instead of using an
> iframe.
>
> Michael
> --
> Michael Darrin Chaney
> mdc...@mi...
> http://www.michaelchaney.com/
>
>
>
>

Re: [Phplib-users] Session/Auth Problem

[Michael C. <mdc...@mi...>]

On Wed, Oct 09, 2002 at 08:56:55AM -0400, Rob Hutton wrote:
> I have auth occurring inside a iframe on my page.  That works correctly and
> that iframe has access to the $sess and $auth variables.  The outer frame
> however does not.  Once I refresh it, the $GLOBALS['Site_Custom_Session']
> variable gives me the same session ID, but $auth and $sess are not defined
> in the outer frame.  Yes, the outer frame does a page_open (in fact, I
> copied and pasted it from the inner frame just to make sure.
> 
> Any Ideas?

Yes.  Don't use frames.

The purpose of the iframe is to allow you to include a bit of HTML from
another site over which you have no control into your current page.
More specifically, they were created to allow fancier banner ads to be
created, html instead of gif's.

What you're doing will always cause problems.  Please don't fool
yourself into thinking that it's possible to do.  The inner and outer
frame may well load somewhat simultaneously, meaning that two different
pages may open your session variables, and subsequently save them back
out.  It's quite possible in that case that changes to session variables
may be lost.  The result will be flakey behavior, such as you've
described.

The correct method is to simply include the code instead of using an
iframe.

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/

Re: [Phplib-users] Another auth peculiarity

[Giancarlo <gia...@na...>]

> > Do you reload the two together when you post the login form in
> > one of the two?
>
> no, only the inner frame
>
> > Do you need authentication in the containing frame too ?-)
>
> yes

Then you simply need to reload the outer frame too...

Gian

RE: [Phplib-users] Another auth peculiarity

[Rob H. <rob...@ws...>]

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Wednesday, October 09, 2002 1:51 PM
> To: phplib-users
> Subject: Re: [Phplib-users] Another auth peculiarity
>
>
> Il 18:54, mercoledì 9 ottobre 2002, hai scritto:
> > Another bit of information, the first time through it looks like auth is
> > being restarted as $auth->auth['uname'] is cleared out.
>
> Sorry, but for cvs php-lib-stable, this must be quite an oldish
> problem, or a
> mistake. I must know:
>
> are you mixing auth and default_auth classes? What auth classes are the 2
> frames using?

No, litterally the same code copied from the inner to outer frame.

> are you placing page_close() too on both the containing and
> contained frames'
> end? This can be the first reason

Yes, the inner and outer frame are two different sessions. (Which may be the
problem)
ex.
{outerframe.php}
page_open();
<HTML>
<BODY>
	<IFRAME src='innerFrame.php'>
</BODY>
</HTML>
page_close();

{end outerframe.php}

{innerframe.php}
page_open();
<HTML>
<BODY>
	This is the inner frame which is another php page.
</BODY>
</HTML>
page_close();

{end innerframe.php}

> Do the two frames show the same sid? (I think you said yes...)

Yes

> Do you reload the two together when you post the login form in
> one of the two?

no, only the inner frame

> Do you need authentication in the containing frame too ?-)

yes

>
> Gian
>
Rob Hutton
Web Safe
www.wsafe.com

Re: [Phplib-users] Another auth peculiarity

[Giancarlo <gia...@na...>]

Il 18:54, mercoled=EC 9 ottobre 2002, hai scritto:
> Another bit of information, the first time through it looks like auth i=
s
> being restarted as $auth->auth['uname'] is cleared out.

Sorry, but for cvs php-lib-stable, this must be quite an oldish problem, =
or a=20
mistake. I must know:

are you mixing auth and default_auth classes? What auth classes are the 2=
=20
frames using?
are you placing page_close() too on both the containing and contained fra=
mes'=20
end? This can be the first reason
Do the two frames show the same sid? (I think you said yes...)
Do you reload the two together when you post the login form in one of the=
 two?
Do you need authentication in the containing frame too ?-)

Gian

[Phplib-users] Network username

[Poduje, M. (LanInfo) <MP...@la...>]

I have my webserver in a Solaris enviroment... But my users come from a
Windows NT network...
How can i get the IP addres and username to put it in php variables?
thanks

RE: [Phplib-users] Another auth peculiarity

[Rob H. <rob...@ws...>]

Another bit of information, the first time through it looks like auth is
being restarted as $auth->auth['uname'] is cleared out.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

View our Symantec Client Security Demo:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271

Download the Symantec Client Security Fact Sheet:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271

Download the Symantec Client Security Brochure:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Wednesday, October 09, 2002 11:38 AM
> To: rob...@ws...; Phplib-Users
> Subject: Re: [Phplib-users] Another auth peculiarity
>
>
> Il 17:12, mercoledì 9 ottobre 2002, Rob Hutton ha scritto:
> > If I am already logged in and run login_if(TRUE) once, then it
> just skips
> > the auth and continues.  If I refresh (run it again) then I get
> the login
> > form.
>
> Sorry, but we're kind of amid a way with this session4 and
> reg_globals off,
> so what versions/setup are you experiencing this? Are you on the cvs
> php-lib-stable, the snapshot, or the distrib?
>
> Gian
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>

RE: [Phplib-users] Another auth peculiarity

[Rob H. <rob...@ws...>]

No problem on the cvs stable.  I downloaded the snapshot, but saw that there
were others having problems with it, so I have not used it.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

View our Symantec Client Security Demo:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271

Download the Symantec Client Security Fact Sheet:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271

Download the Symantec Client Security Brochure:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271


> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Wednesday, October 09, 2002 11:38 AM
> To: rob...@ws...; Phplib-Users
> Subject: Re: [Phplib-users] Another auth peculiarity
>
>
> Il 17:12, mercoledì 9 ottobre 2002, Rob Hutton ha scritto:
> > If I am already logged in and run login_if(TRUE) once, then it
> just skips
> > the auth and continues.  If I refresh (run it again) then I get
> the login
> > form.
>
> Sorry, but we're kind of amid a way with this session4 and
> reg_globals off,
> so what versions/setup are you experiencing this? Are you on the cvs
> php-lib-stable, the snapshot, or the distrib?
>
> Gian
>
>

[Phplib-users] Session issue

[Rob H. <rob...@ws...>]

  There was a discussion somewhere that I read (either in tracker or in the
archives) about whether or not setup.inc should be run at each session setup
or just once.  There was never any real resolution, so I wanted to reask.
  Setup.inc seems to me to be the place that things should be done during
session setup.  I have modified the example script to log some more
information into session_stats.  I also need to initialize my own security
system with the list of attributes.  The problem is, since it is only run
once, I have to go modify the library to address this.  Should it be run
every time, should there be two files like oneTimeSessionSetup.inc and
sessionSetup.inc, or should it be a flag.  I personally would vote for
number 2.  Then the one time things and the every time things could be
handled.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

View our Symantec Client Security Demo:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=3&PID=11624271

Download the Symantec Client Security Fact Sheet:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=4&PID=11624271

Download the Symantec Client Security Brochure:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=5&PID=11624271

Re: [Phplib-users] snapshots available on sf.net

[Joe S. <jo...@cm...>]

On Tue, Oct 08, 2002 at 10:49:32AM +0200, Marko Kaening wrote:
> Hi Joe,
> 
> > A request to please test the snapshots on sf.net:
> > 	http://phplib.sourceforge.net/snapshots/
> 
> I installed this snapshot and it seems to work with my app without
> problems. The only strange behaviour I noticed is that during loading of
> the loginform I get the following PHP notices:
> 
>  [Tue Oct  8 09:53:42 2002] [error] PHP Notice:  Undefined index:
>  username in /usr/local/lib/phplib-0.74.20021007.patches/php/local.inc on
>  line 175
> 
> I use the Challenge_Crypt_Auth class, which nobody seems to have looked at
> with latest changes.
> Here username is used in the sql-select in auth_validatelogin() eventhough
> it's undefined, instead the select should be circumvented if the username
> wasn't defined yet.

Okay corrected.  The select shouldn't even be done if the username isn't 
submitted.

> I wonder whether the formids functionality could be transferred also to
> this class?
> 

A little tweak to the challenge auth provides this functionality.  It 
expires the challenge word after a succeful login.

> 
>  [Tue Oct  8 09:53:42 2002] [error] PHP Notice:  Undefined variable:  sess
>  in /usr/local/lib/phplib-0.74.20021007.patches/php/auth.inc on line 109
> 
> $sess should be global in start_actions()!
> 
> 
>  [Tue Oct  8 10:32:25 2002] [error] PHP Notice:  Undefined property:
>  newid in /usr/local/lib/phplib-0.74.20021007.patches/php/auth.inc on
>  line 110
> 
> Var newid is obviously not created and cannot be used in the same
> function. I use PHP4 sessions in files mode.
> 

Okay, I made php happy, but Gian may just want to change the newid 
conditional.

> 
>  [Tue Oct  8 09:53:42 2002] [error] PHP Notice:  Undefined index:  mode
>  in /usr/local/lib/phplib-0.74.20021007.patches/php/page.inc on line 95
> 
> It should read I guess:
> 
>  $mode=(isset($HTTP_GET_VARS['mode']) ? .....
> 
> 

Gian?

> 
> Otherwise everything seems to work as expected. No further problems up to
> now.
> 
> 

Thanks for the feedback,

Joe

> Good luck,
> Marko

Re: [Phplib-users] Another auth peculiarity

[Giancarlo <gia...@na...>]

Il 17:12, mercoled=EC 9 ottobre 2002, Rob Hutton ha scritto:
> If I am already logged in and run login_if(TRUE) once, then it just ski=
ps
> the auth and continues.  If I refresh (run it again) then I get the log=
in
> form.

Sorry, but we're kind of amid a way with this session4 and reg_globals of=
f,=20
so what versions/setup are you experiencing this? Are you on the cvs=20
php-lib-stable, the snapshot, or the distrib?

Gian

[Phplib-users] Another auth peculiarity

[Rob H. <rob...@ws...>]

If I am already logged in and run login_if(TRUE) once, then it just skips
the auth and continues.  If I refresh (run it again) then I get the login
form.

Rob Hutton
Web Safe
www.wsafe.com

RE: [Phplib-users] 2 Problems (Reset Button + Template Problem)

[Benjamin H. <ho...@eu...>]

call by reference thats what i was searching for ;)

works fine now ;)

> ----------
> From: 	Layne Weathers[SMTP:la...@if...]
> Reply To: 	la...@if...
> Sent: 	09 October 2002 15:37
> To: 	'Benjamin Hoft'; php...@li...
> Subject: 	RE: [Phplib-users] 2 Problems (Reset Button + Template Problem)
> 
> > > printallNEWS($t);
> > >
> > > function printallNEWS($t)
> 
> Change your function declaration to:
> 
> 	function printallNEWS(&$t)
> 	{
> 		....
> 	}
> 
> Note the ampersand - that will tell the function to reference your template
> object rather than copy it to a new object that is lost after the function
> runs. Alternatively, if you only ever use one template object you could:
> 
> 	function printallNEWS()
> 	{
> 		global $t;
> 		....
> 	}
> 
> 
> Layne Weathers
> Ifworld Inc.
>