phplib-users

RE: [Phplib-users] auth url question

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

The more I think about this, the less I agree, because I think that auth
logic was/is flawed.  But attached is a version that I think will drop in.

IMHO, auth should have a definite structure.  It should not be something
where this and that gets tried until something happens to work.  And in the
case of registration, you could type an existing user name and password and
get in.  And that is not acceptable on a site that deals with credit cards,
or business presentation, or a lot of things.  I don't agree with the way
that registration is implemented in PHPSlash because it could be used on a
business site and someone could fairly easily do something to defame the
business by finding a loophole in the auth logic.

Thanks,
Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: Giancarlo Pinerolo [mailto:gia...@na...]
> Sent: Wednesday, October 30, 2002 1:59 PM
> To: rob...@ws...
> Subject: Re: [Phplib-users] auth url question
>
>
> Rob Hutton wrote:
> >
> > It is partially fixed in session.inc, but not in session4.inc which I am
> > using.
>
> session.inc (session3), always used HTTP_SERVER_VARS[QUERY_STRING].
> I am sure session4 in snapshot has been fixed too quite some time ago.
> The one I've downloded just now has (20021022.dev).
>
> I think the sanpshot is a delicate balance of  compromises that
> actually works on phplib native sessions too (session3) and can be
> used as a drop-in replacement that will work in most existing sites,
> except (probably, but may be not true) on PHP3 sites. And (if we want
> to) to accomplish this goal we have to provide for those sites that
> used to implement login_if() in their pages.
>
> Gian
>
>
>
>

Re: [Phplib-users] auth url question

[Matt W. <li...@ye...>]

On Thursday 31 October 2002 14:23, Rob Hutton wrote:
> The more I think about this, the less I agree, because I think that aut=
h
> logic was/is flawed.  But attached is a version that I think will drop =
in.

hi all

I've missed most of this thread so forgive me if I've missed something or=
 am
heading off in the wrong direction.

=46rom what I gather a summary of this thread is about using mode=3Dreg o=
r
something similar in the url to invoke registration, is this correct?

=46rom my point of the view this would be a waste of time. Each applicati=
on
 that I use phplib on invariably has different requirements for registrat=
ion.
 For me it is easier to keep registration to it's own page where I can
 control error checking on the form fields, add/remove fields as I wish
 without having to worry about anything in phplib that might get
 broken/compromised in the process.

IMHO it seems like that the project has lost it's way a little in terms o=
f
what it should do, what it needs to do as a project as a whole and what
people feel it should do to best help them.

What I think needs to happen is to maybe have a more defined development
 path, possibly. For someone to say, right that's it for new stuff to go =
in,
 let's get it tested and out.
Just looking at the task manager on sourceforge shows the is very little =
in
the way of defined goals for each release. If something good comes up fro=
m
feature requests or from someones own development, then fine add it in as
long as it's not gonna put too much on the next release and only if it's =
for
the benefit of the project as a whole.

So for example it has been discussed about getting the latest dev out for
testing then release. I think this would be a good idea, but only as long=
 as
no more extra stuff keeps getting added in in the meantime. If we do this
we'll never get it our of the door.

The main aim of the next release seems to be to get it working with php4
sessions and register globals off. So we should get this tested, debugged=
 and
released. Then and, only then would it be time to move on.

my 2p

matt

-------------------------------------------------------

Re: [Phplib-users] auth url question

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

Thank you Matt.

On Thu, Oct 31, 2002 at 02:53:58PM +0000, Matt Williams wrote:
> 
snip!
> 
> The main aim of the next release seems to be to get it working with php4
> sessions and register globals off. So we should get this tested, debugged and
> released. Then and, only then would it be time to move on.
>

This is the current state of cvs.  These were the only changes made to the 
cvs and thus the cvs snapshot.

Perhaps unfortunately there hasn't been much discussion of this.  

All discussion has been about the dev snapshot which is good that 
development discussion is happening, but I would much rather see on a 
dedicated phplib developer list.

I created the dev snapshot because there didn't seem to be any discussion 
or feedback to the patches applied to sf.net. 

Joe


> my 2p
> 
> matt
> 

RE: [Phplib-users] auth url question

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

I disagree on two points.

1) I am new to the php-lib world, but from what I have been told, the 7.2
stuff is much more structured that the curent development stuff, and this is
the core issue that I see.

2) Registration may have special needs, but this is the point of having
local.inc.  Single, two-phase, and approval based registration can easliy be
offered as examples, and probably be used "off the shelf" in a lot of
circumstances...

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Matt
> Williams
> Sent: Thursday, October 31, 2002 9:54 AM
> To: Phplib-Users
> Subject: Re: [Phplib-users] auth url question
>
>
>
> On Thursday 31 October 2002 14:23, Rob Hutton wrote:
> > The more I think about this, the less I agree, because I think that auth
> > logic was/is flawed.  But attached is a version that I think
> will drop in.
>
> hi all
>
> I've missed most of this thread so forgive me if I've missed
> something or am
> heading off in the wrong direction.
>
> From what I gather a summary of this thread is about using mode=reg or
> something similar in the url to invoke registration, is this correct?
>
> From my point of the view this would be a waste of time. Each application
>  that I use phplib on invariably has different requirements for
> registration.
>  For me it is easier to keep registration to it's own page where I can
>  control error checking on the form fields, add/remove fields as I wish
>  without having to worry about anything in phplib that might get
>  broken/compromised in the process.
>
> IMHO it seems like that the project has lost it's way a little in terms of
> what it should do, what it needs to do as a project as a whole and what
> people feel it should do to best help them.
>
> What I think needs to happen is to maybe have a more defined development
>  path, possibly. For someone to say, right that's it for new
> stuff to go in,
>  let's get it tested and out.
> Just looking at the task manager on sourceforge shows the is very
> little in
> the way of defined goals for each release. If something good comes up from
> feature requests or from someones own development, then fine add it in as
> long as it's not gonna put too much on the next release and only
> if it's for
> the benefit of the project as a whole.
>
> So for example it has been discussed about getting the latest dev out for
> testing then release. I think this would be a good idea, but only
> as long as
> no more extra stuff keeps getting added in in the meantime. If we do this
> we'll never get it our of the door.
>
> The main aim of the next release seems to be to get it working with php4
> sessions and register globals off. So we should get this tested,
> debugged and
> released. Then and, only then would it be time to move on.
>
> my 2p
>
> matt
>
> -------------------------------------------------------
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

Re: [Phplib-users] auth url question

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

Il 15:53, gioved=EC 31 ottobre 2002, Matt Williams ha scritto:
> On Thursday 31 October 2002 14:23, Rob Hutton wrote:
> > The more I think about this, the less I agree, because I think that a=
uth
> > logic was/is flawed.  But attached is a version that I think will dro=
p
> > in.
>
> hi all
>
> I've missed most of this thread so forgive me if I've missed something =
or
> am heading off in the wrong direction.
>
> From what I gather a summary of this thread is about using mode=3Dreg o=
r
> something similar in the url to invoke registration, is this correct?
>
> From my point of the view this would be a waste of time. Each applicati=
on
>  that I use phplib on invariably has different requirements for
> registration. For me it is easier to keep registration to it's own page
> where I can control error checking on the form fields, add/remove field=
s as
> I wish without having to worry about anything in phplib that might get
>  broken/compromised in the process.
>

I perfectly agree with this you said.=20
The least we get HTTP_GET/POST_VARS hardcoded in the main start() functio=
n,=20
the better it is for people to extend phplib to their needs.
I myself like to have the possibility, from my proper version of page.inc=
=20
(this means BEFORE invoking auth->start) to invoke separately, depending =
on=20
my needs, any and each of the 3 main function start does:=20
authenticate/login/register

Gian

RE: [Phplib-users] auth url question

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

> >
>
> I perfectly agree with this you said.
> The least we get HTTP_GET/POST_VARS hardcoded in the main start()
> function,
> the better it is for people to extend phplib to their needs.
> I myself like to have the possibility, from my proper version of page.inc
> (this means BEFORE invoking auth->start) to invoke separately,
> depending on
> my needs, any and each of the 3 main function start does:
> authenticate/login/register
>
But the URL is not hardcoded into anything!  It is a variable, and with the
duplicated functionality of login_if, then it can be called at start or
afterwards.  My concern is not how it is called, it is that start as it is
in the snapshot is unstructured.  It just calls stuff until something
happens.  And that is not good.

RE: [Phplib-users] auth url question

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

Why do all three need to be run, the example that I sent handles all three,
but it does so in a structured fashion.  The only one that gets run is what
is asked for.  And that is the whole point.  Auth should try only what it is
inetentionally told to try.  Not try everything until something works...

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Thursday, October 31, 2002 4:08 PM
> To: rob...@ws...
> Cc: Phplib-Users
> Subject: Re: [Phplib-users] auth url question
>
>
> Il 15:23, giovedì 31 ottobre 2002, Rob Hutton ha scritto:
> > The more I think about this, the less I agree, because I think that auth
> > logic was/is flawed.  But attached is a version that I think
> will drop in.
> >
> > IMHO, auth should have a definite structure.  It should not be something
> > where this and that gets tried until something happens to work.
>  And in the
> > case of registration, you could type an existing user name and
> password and
> > get in.  And that is not acceptable on a site that deals with
> credit cards,
> > or business presentation, or a lot of things.
>
> auth_validatelogin and auth_doregister are in userland local.inc.
> A register
> form and a auth_doregister function is not even provided as an example.
> Add an input field to the register form, eg
> <input name=action value=register> and test it in auth_doregister.
> Same for validating the login, add
> <input name=actio value=login> in the loginform and test it in
> auth_validatelogin.
>
> Otherwise we cannot simply call auth->start and pretend it will do, by
> itself, any/everything needed. We'll need to call the three main start
> functions separately, as auth->start(authenticate), auth->start(login),
> auth->start(register). And this is definetely what I'd prefer.
>
> G
>
>

Re: [Phplib-users] auth url question

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

Il 22:17, gioved=EC 31 ottobre 2002, Rob Hutton ha scritto:
> Why do all three need to be run, the example that I sent handles all th=
ree,
> but it does so in a structured fashion.  The only one that gets run is =
what
> is asked for.  And that is the whole point.  Auth should try only what =
it
> is inetentionally told to try.  Not try everything until something work=
s...

Then I prefer to call exactly what I want auth->start to do.

So, eg (quick code), in page.inc:

  if($whatever_we_want =3D=3D "auth")
   $auth->start('authenticate')
  elsif ($whatever_we_want =3D=3D "login")
   $auth->start('login')
  elsif ($whatever_we_want =3D=3D "register")
   $auth->start('register')

That gives a lot more possibilities, because is done before and instead o=
f=20
calling the whole auth->start, and doesn't rely on any cascade logic, nor=
=20
defers the trigger testing, to auth->start. I want to decide what auth=20
function to call  case by case.
With thsi structure it it more feasable to pilot the behaviour of auth, e=
g=20

> Single, two-phase, and approval based registration=20

as you said, could easliy be added like this, in page inc

### this mimics the auth->auth[uid]=3D=3D'form' blocking login state
if($sess_login_in_progress) {=20
    if(!$auth->start('login') {
       page_showform();
    }
}

## this mimics the actual behavior
  if( ! $auth->start('authenticate') && (!$auth->start('login'))
    $auth->start('register')

etc.

By having these three functionalities at hand, *separately, we can combin=
e=20
them to get the  behaviors we want *out of, and apart from, the start met=
hod*

Gian





>
> > -----Original Message-----
> > From: Giancarlo [mailto:gia...@na...]
> > Sent: Thursday, October 31, 2002 4:08 PM
> > To: rob...@ws...
> > Cc: Phplib-Users
> > Subject: Re: [Phplib-users] auth url question
> >
> > Il 15:23, gioved=EC 31 ottobre 2002, Rob Hutton ha scritto:
> > > The more I think about this, the less I agree, because I think that
> > > auth logic was/is flawed.  But attached is a version that I think
> >
> > will drop in.
> >
> > > IMHO, auth should have a definite structure.  It should not be
> > > something where this and that gets tried until something happens to
> > > work.
> >
> >  And in the
> >
> > > case of registration, you could type an existing user name and
> >
> > password and
> >
> > > get in.  And that is not acceptable on a site that deals with
> >
> > credit cards,
> >
> > > or business presentation, or a lot of things.
> >
> > auth_validatelogin and auth_doregister are in userland local.inc.
> > A register
> > form and a auth_doregister function is not even provided as an exampl=
e.
> > Add an input field to the register form, eg
> > <input name=3Daction value=3Dregister> and test it in auth_doregister=
=2E
> > Same for validating the login, add
> > <input name=3Dactio value=3Dlogin> in the loginform and test it in
> > auth_validatelogin.
> >
> > Otherwise we cannot simply call auth->start and pretend it will do, b=
y
> > itself, any/everything needed. We'll need to call the three main star=
t
> > functions separately, as auth->start(authenticate), auth->start(login=
),
> > auth->start(register). And this is definetely what I'd prefer.
> >
> > G

MO: [Phplib-users] auth url question

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

> > Single, two-phase, and approval based registration
>
> as you said, could easliy be added like this, in page inc
>

### this mimics the auth->auth[uid]=='form' blocking login state
 if($sess_login_in_progress) 
     {
     if(!$auth->start('login') 
        {
        page_showform();
        }
     else
        {
        unset ($sess_login_in_progress);
        }
     }




>
> ## this mimics the actual behavior
>   if( ! $auth->start('authenticate') && (!$auth->start('login'))
>     $auth->start('register')

actually, the latter should be so:

 ## this mimics the actual behavior: cascade
   if((!$auth->start('authenticate')) 
     && (!$auth->start('login'))
     && (!$auth->start('register')) {
      page_showform();
   }

I can think more, 

 ## no cascade 
   if((!$auth->start('authenticate'))
     { 
     if( ($whatever_trigger == 'login' && !$auth->start('login'))
         ||($whatever_trigger == 'register')&& (!$auth->start('register')) 
         {
         page_showform();
         }
     }         
     

What do you mean by 'two phase' and 'approval based' registration? What 
should be the steps?


Gian



> By having these three functionalities at hand, *separately, we can combine
> them to get the  behaviors we want *out of, and apart from, the start
> method*
>
> Gian

MO: MO: [Phplib-users] auth url question

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

> I can think more,
>
>  ## no cascade
>    if((!$auth->start('authenticate'))
>      {
>      if( ($whatever_trigger == 'login' && !$auth->start('login'))
>
>          ||($whatever_trigger == 'register')&& (!$auth->start('register'))
>
>          {
>          page_showform();
>          }
>      }
>


The point is also that we should still be able of calling auth->start() the 
usual way, without any parameter, and be compatible with existing sites.

Gian

RE: [Phplib-users] auth url question

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

OK, Joe and I had this disccussion too.  He wanted a function similar to
login_if, so I called it do_auth().  Same concept.  If you want to run auth
in the url mode, then start handles it.  If you want to run it in command
mode, that works too.

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Thursday, October 31, 2002 4:50 PM
> To: rob...@ws...
> Cc: Phplib-Users
> Subject: Re: [Phplib-users] auth url question
>
>
> Il 22:17, giovedì 31 ottobre 2002, Rob Hutton ha scritto:
> > Why do all three need to be run, the example that I sent
> handles all three,
> > but it does so in a structured fashion.  The only one that gets
> run is what
> > is asked for.  And that is the whole point.  Auth should try
> only what it
> > is inetentionally told to try.  Not try everything until
> something works...
>
> Then I prefer to call exactly what I want auth->start to do.
>
> So, eg (quick code), in page.inc:
>
>   if($whatever_we_want == "auth")
>    $auth->start('authenticate')
>   elsif ($whatever_we_want == "login")
>    $auth->start('login')
>   elsif ($whatever_we_want == "register")
>    $auth->start('register')
>
> That gives a lot more possibilities, because is done before and
> instead of
> calling the whole auth->start, and doesn't rely on any cascade logic, nor
> defers the trigger testing, to auth->start. I want to decide what auth
> function to call  case by case.
> With thsi structure it it more feasable to pilot the behaviour of
> auth, eg
>
> > Single, two-phase, and approval based registration
>
> as you said, could easliy be added like this, in page inc
>
> ### this mimics the auth->auth[uid]=='form' blocking login state
> if($sess_login_in_progress) {
>     if(!$auth->start('login') {
>        page_showform();
>     }
> }
>
> ## this mimics the actual behavior
>   if( ! $auth->start('authenticate') && (!$auth->start('login'))
>     $auth->start('register')
>
> etc.
>
> By having these three functionalities at hand, *separately, we
> can combine
> them to get the  behaviors we want *out of, and apart from, the
> start method*
>
> Gian
>
>
>
>
>
> >
> > > -----Original Message-----
> > > From: Giancarlo [mailto:gia...@na...]
> > > Sent: Thursday, October 31, 2002 4:08 PM
> > > To: rob...@ws...
> > > Cc: Phplib-Users
> > > Subject: Re: [Phplib-users] auth url question
> > >
> > > Il 15:23, giovedì 31 ottobre 2002, Rob Hutton ha scritto:
> > > > The more I think about this, the less I agree, because I think that
> > > > auth logic was/is flawed.  But attached is a version that I think
> > >
> > > will drop in.
> > >
> > > > IMHO, auth should have a definite structure.  It should not be
> > > > something where this and that gets tried until something happens to
> > > > work.
> > >
> > >  And in the
> > >
> > > > case of registration, you could type an existing user name and
> > >
> > > password and
> > >
> > > > get in.  And that is not acceptable on a site that deals with
> > >
> > > credit cards,
> > >
> > > > or business presentation, or a lot of things.
> > >
> > > auth_validatelogin and auth_doregister are in userland local.inc.
> > > A register
> > > form and a auth_doregister function is not even provided as
> an example.
> > > Add an input field to the register form, eg
> > > <input name=action value=register> and test it in auth_doregister.
> > > Same for validating the login, add
> > > <input name=actio value=login> in the loginform and test it in
> > > auth_validatelogin.
> > >
> > > Otherwise we cannot simply call auth->start and pretend it will do, by
> > > itself, any/everything needed. We'll need to call the three main start
> > > functions separately, as auth->start(authenticate),
> auth->start(login),
> > > auth->start(register). And this is definetely what I'd prefer.
> > >
> > > G
>

RE: [Phplib-users] auth url question

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

  I don't agree with this approach because you are putting auth control
logic inside page and best practices are that the logic should reside in the
object itself.  My questions is whether login and register should be
separate objects.

  Two phased registration is where you register and then have to "activate"
the account via an email or some other process activates the account and
notifies you such as when a credit card has been approved.

  Approval registration is the same process as two phase, but instead of the
account being automaticly enabled by some means, the moderator must enable
the account.

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Thursday, October 31, 2002 5:17 PM
> To: rob...@ws...
> Cc: Phplib-Users
> Subject: MO: [Phplib-users] auth url question
>
>
>
> > > Single, two-phase, and approval based registration
> >
> > as you said, could easliy be added like this, in page inc
> >
>
> ### this mimics the auth->auth[uid]=='form' blocking login state
>  if($sess_login_in_progress)
>      {
>      if(!$auth->start('login')
>         {
>         page_showform();
>         }
>      else
>         {
>         unset ($sess_login_in_progress);
>         }
>      }
>
>
>
>
> >
> > ## this mimics the actual behavior
> >   if( ! $auth->start('authenticate') && (!$auth->start('login'))
> >     $auth->start('register')
>
> actually, the latter should be so:
>
>  ## this mimics the actual behavior: cascade
>    if((!$auth->start('authenticate'))
>      && (!$auth->start('login'))
>      && (!$auth->start('register')) {
>       page_showform();
>    }
>
> I can think more,
>
>  ## no cascade
>    if((!$auth->start('authenticate'))
>      {
>      if( ($whatever_trigger == 'login' && !$auth->start('login'))
>          ||($whatever_trigger == 'register')&&
> (!$auth->start('register'))
>          {
>          page_showform();
>          }
>      }
>
>
> What do you mean by 'two phase' and 'approval based' registration? What
> should be the steps?
>
>
> Gian
>
>
>
> > By having these three functionalities at hand, *separately, we
> can combine
> > them to get the  behaviors we want *out of, and apart from, the start
> > method*
> >
> > Gian
>

Re: [Phplib-users] auth url question

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

Il 15:23, gioved=EC 31 ottobre 2002, Rob Hutton ha scritto:
> The more I think about this, the less I agree, because I think that aut=
h
> logic was/is flawed.  But attached is a version that I think will drop =
in.
>
> IMHO, auth should have a definite structure.  It should not be somethin=
g
> where this and that gets tried until something happens to work.  And in=
 the
> case of registration, you could type an existing user name and password=
 and
> get in.  And that is not acceptable on a site that deals with credit ca=
rds,
> or business presentation, or a lot of things.=20

auth_validatelogin and auth_doregister are in userland local.inc. A regis=
ter=20
form and a auth_doregister function is not even provided as an example.=20
Add an input field to the register form, eg=20
<input name=3Daction value=3Dregister> and test it in auth_doregister.
Same for validating the login, add=20
<input name=3Dactio value=3Dlogin> in the loginform and test it in=20
auth_validatelogin.

Otherwise we cannot simply call auth->start and pretend it will do, by=20
itself, any/everything needed. We'll need to call the three main start=20
functions separately, as auth->start(authenticate), auth->start(login),=20
auth->start(register). And this is definetely what I'd prefer.

G
=20