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