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

Re: [Phplib-users] again auth.inc and perm.inc !

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

Michael Chaney wrote:
> I hate to beat a dead horse, but I have fixed all of this in my phpauth
> code:
> 
> http://www.phpauth.com/
> 
> I've been using phplib for a number of years, and finally decided to
> rewrite the parts that needed to be fixed.  All the problems that you
> and Giancarlo bring up are problems that I recognized over a year ago,
> and I've spent that year fixing them.  Please don't duplicate effort.

You mean we should integrate it into phplib? Or that we should migrate
to phpauth?

I've seen phpauth, but phplib has a wealth of features that phpauth
doesn't have. I thinkk actual users of phplib would miss them.

If you are proposing to integrate, let's have a look.
My auth.inc works 100% within the phplib framework. Any site using
phplib will not notice the substitution. 
In fact the new method start is really barebone, and the
login_in_process state flag can be added in a breeze.
To integrate phpauth into the eisting phplib frame I think would require
more work than that.

But it's all 'a debatre', to be discussed.

Gian

Re: [Phplib-users] again auth.inc and perm.inc !

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

Guillaume Desclaux wrote:

> Using session to store the pre_login_state of auth class seems to be a good
> idea to avoid the "vicious circle" of an auth class not ready
> authenticated... and avoid to use auth[uid] as a flag seems to be a really
> good idea too...

That is the main point. 

> sheme... so we need to have a real user/group/perm sheme.
> 
> I've built a perm.inc like that using an email from Kristian... and I've
> submited my code to Richard for examination, but Richard seems to be very
> hard working, so he has no time to see it. If anybody want to see it, I'll be
> happy to share that code... and I'll be happier to see this code included in
> the next version of version phplib...

I also have used KK user/group extension. PHPBT (bug tracker) adopted it
since the beginning, when phpbt was based on phplib. Now he's gone his
own way with auth, but still has that user/group code.

KK extension only  misses the possibility to add groups to groups, a la
/etc/group

Gian

Re: [Phplib-users] again auth.inc and perm.inc !

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

On Mon, Jun 10, 2002 at 12:27:52PM +0200, Guillaume Desclaux wrote:
> I've not really follow this discussion closely but i cannot disagree that the
> code of auth.inc is pretty much hard to maintain... and that it is very hard
> to code a phpnuke login style with it... and the default_auth is not very
> helping... so the code of the auth.class is probably not exactly what we need
> now...
> 
> So, the suggestion of Giancarlo make sens for me, but it is an evidence that
> we need to examine closely the "secondary effect" of these kind of
> modification in the structure of the auth class ...
> 
> Using session to store the pre_login_state of auth class seems to be a good
> idea to avoid the "vicious circle" of an auth class not ready
> authenticated... and avoid to use auth[uid] as a flag seems to be a really
> good idea too...

I hate to beat a dead horse, but I have fixed all of this in my phpauth
code:
 
http://www.phpauth.com/
  
I've been using phplib for a number of years, and finally decided to
rewrite the parts that needed to be fixed.  All the problems that you
and Giancarlo bring up are problems that I recognized over a year ago,
and I've spent that year fixing them.  Please don't duplicate effort.

> Moreover... the perm.inc should be probably redesigned... the use of a
> bitmask is a great idea in a vision of phplib used to build a simple
> application... but phplib is now involved in "large" project : a web site
> with many "little" application... each application needed is own perm
> sheme... so we need to have a real user/group/perm sheme.

Also fixed in phpauth.

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

Re: [Phplib-users] again auth.inc and perm.inc !

[Guillaume D. <gde...@pr...>]

I've not really follow this discussion closely but i cannot disagree that the
code of auth.inc is pretty much hard to maintain... and that it is very hard
to code a phpnuke login style with it... and the default_auth is not very
helping... so the code of the auth.class is probably not exactly what we need
now...

So, the suggestion of Giancarlo make sens for me, but it is an evidence that
we need to examine closely the "secondary effect" of these kind of
modification in the structure of the auth class ...

Using session to store the pre_login_state of auth class seems to be a good
idea to avoid the "vicious circle" of an auth class not ready
authenticated... and avoid to use auth[uid] as a flag seems to be a really
good idea too...

Moreover... the perm.inc should be probably redesigned... the use of a
bitmask is a great idea in a vision of phplib used to build a simple
application... but phplib is now involved in "large" project : a web site
with many "little" application... each application needed is own perm
sheme... so we need to have a real user/group/perm sheme.

I've built a perm.inc like that using an email from Kristian... and I've
submited my code to Richard for examination, but Richard seems to be very
hard working, so he has no time to see it. If anybody want to see it, I'll be
happy to share that code... and I'll be happier to see this code included in
the next version of version phplib...

Guillaume

PS: sorry for my bad english...

Re: [Phplib-users] again auth.inc

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

> 
> If you need the intermediate state, even in the same auth[uid] place, I
> can add it to page_open.

Well, we'd go into the same insanity. The mistake was to use an
$auth->auth[] field to hold the login_in_progress state. Which needed to
have an auth object first! If we'd used an e.g. $sess->login_in_progress
state field, we'd been much better, with the same result: be assured
that a form has been shown somehow.

Anyway you must understand that the intermediate 'login_in_progress'
('form') state, if set anywhere into $auth->auth[],  will block all
other pages, and makes sense only whe you want to have an unique, global
policy. It is not compatible with the 'case_by_case' policy, php-nuke
style. 

If you prefer the case_by_case policy and *still* like to have the extra
check of a login_in_progress state flag, you cannot put it in the auth
object, but rather put it in the sess object. That makes no difference
on the security, 
G

> When it shows the form it will set that, upon considering the input
> fields it will check that.

But then I'd have to reintroduce the cancel_login stuff. If I use a
$sess->login_in_progress field, other pages can still have $auth, but
nevertheless $sess-<login_in_progress it can be checked before
considering $username input fields.

Gian

[Phplib-users] new.auth.inc

[Andrey L. <an...@nk...>]

Hi,=20
I like an idea of new auth class by Giancarlo, but i'm actually can't
make it work as i wish. I hope Gian or any body who are using this patch
can help...:)

I'm currently starting a new project. Authentication is supposed to look
like in phpNuke or such. I mean anonymous users will see login box
somewere, but after they presses submit button (in any page), box
disappears.

So i override Auth as follows:

//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
class Auth_MW extends Auth {
	var $classname =3D "Auth_MW";
	var $lifetime =3D 0;
	var $nobody =3D false;

	function auth_preauth() {
		print "Preauth<br>";
	}
	function auth_validatelogin() {
		print "validatelogin.<br>";
	}
	function auth_loginform() {
		print "this is a login form.<br>";
	}
}
//=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

now when $nobody is false, the last thing outputed is "this is a login
form.".

when $nobody us set to true, i see whole page, but nothing except
auth_preauth is calling.

So i want to ask how to implement authentication in a RIGHT way. Of
course i could check was there form submittion in a auth_preauth and
then try to auth_validatelogin... But how do you suggests?

Thanks.

P.S. sorry for bad english...:) i hope you understand me

--=20
Andrey Lebedev
Naujoji Komunikacija

Re: [Phplib-users] again auth.inc

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

Giancarlo Pinerolo wrote:
> 
> The auth->start logic IS very simple, we made it complicate in the past
> for no reason.
> 
> It is more or less like this:
> 
> The user has valid auth[uid]?
>      if yes return UID.
> 
> The user has no auth[uid]?
>    if there he's provoding username+password lets' try to register him
>        if registration goes OK return UID
>    if there he's providing a username let's try to log him in
>        if login return true return UID
>    all other cases return false.
> 
> That's all folks!
> 
> Then the outer function, page_start, decides what to do, upon calling
> $auth->start
> 
> If auth has returned false, we can decide either a global policy of
> login/register forms for all cases, as phplib is now,  with the same
> full-blown login pages for the whole site

In this case, phplib works exactly as before. You can put the auth.inc
in place an all your site continues to work as usual

> Otherwise set a global switch, or an $auth->auth[switch], that the very
> particular pages can test and decide case by case what to do: show only
> part of the content + a loginform somewhere, show a full blown, halting,
> loginform, somewhere else, show exactly the same stuff to everyone + a
> 'welcome back my friend' in case he's authed, do nothing.

In this case you decide that you are not going to have a glonbal
behaviour, but want to decide case by case.

If you need the intermediate state, even in the same auth[uid] place, I
can add it to page_open. 
When it shows the form it will set that, upon considering the input
fields it will check that.
And the whole auth->start code is much more clean, with exactly the same
inner behavior, using exactly the same field. Jus moved to somewhere
more readable and easily twicklable

Gian
> No more 'nobody', no more 'form' status, no more 'cancel_login', no more
> unmaintainable code, no more limits and workaround on how and where to
> show the forms, no more problems.
> 
> Hard?
> 
> G

[Phplib-users] Re: more auth->start woes

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

Giancarlo Pinerolo wrote:
> 
> But the final drop was whBut the final drop was when  realized that
> $auth->auth[uid] could be passed from outside. If you clean all your
> cookies an restart the browser (or disable cookies all the way), and
> open
> 
> showoff.php3?Example_Session=form
> 
> your auth[uid] is now 'form'. 

No, I am deadly wrong! Excuse me. That had to be Example_Auth=form,
which cannot be passed in the URL.

Forget that message at all.

Gian

[Phplib-users] more auth->start woes

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

But the final drop was whBut the final drop was when  realized that
$auth->auth[uid] could be passed from outside. If you clean all your
cookies an restart the browser (or disable cookies all the way), and
open

showoff.php3?Example_Session=form

your auth[uid] is now 'form'. You are in the 'login in progress' status.
If you add some POST data input as $userame and password, I bet you can
register, without the form being submitted.
As the goal of auth[uid]==form was to be assured that the form was
previously shown somewhere before considering the input fields, this
defeats also that only advantage of that intermediate status

So for me is broken.

Gian

PS with the latest cvs version f php-lib-stable this behaviour doesn't
wors anymore because user input is no more trusted on session creation,
but before it was like that

And I sulevate you about the mode=log/reg stuff, which want 'states
centrally' what is the global policy... impeding you to decide case by
case.

Re: [Phplib-users] again auth.inc

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

The auth->start logic IS very simple, we made it complicate in the past
for no reason.

It is more or less like this:

The user has valid auth[uid]?
     if yes return UID.

The user has no auth[uid]?
   if there he's provoding username+password lets' try to register him
       if registration goes OK return UID
   if there he's providing a username let's try to log him in
       if login return true return UID   
   all other cases return false.

That's all folks! 

Then the outer function, page_start, decides what to do, upon calling
$auth->start

If auth has returned false, we can decide either a global policy of
login/register forms for all cases, as phplib is now,  with the same
full-blown login pages for the whole site

Otherwise set a global switch, or an $auth->auth[switch], that the very
particular pages can test and decide case by case what to do: show only
part of the content + a loginform somewhere, show a full blown, halting,
loginform, somewhere else, show exactly the same stuff to everyone + a 
'welcome back my friend' in case he's authed, do nothing.  

No more 'nobody', no more 'form' status, no more 'cancel_login', no more
unmaintainable code, no more limits and workaround on how and where to
show the forms, no more problems.

Hard?

G

Re: [Phplib-users] again auth.inc and forms phpnuke like

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

Matteo Sgalaberni wrote:
> 
> I'm again about managing authentication like "phpnuke":
> 
> - a login form is displayed only when the user is not auth
> - the form is hidden if the user is authenticated
> 
> The Auth Class was originally designed mainly by Massimiliano
> Masserelli(aka negro) and it's problem to solve was:
> 
> - If a page require that a user is authenticated, phplib auth it. And
>   was implemented the automated states that changes in order to cover
>   all problems related.
> 

I remember when he did that. After a few weeks, when we found that one
could not hit the back button, someone added the cancel_login stuff...
Which anyway doesn't solve the fact that you cannot access a
defalult-auth page, not even with another browser window, when a login
form is out anywhere....

I tell you, it's all badly broken. 
The default_auth idea is broken too, because it's only use is to avoid
the show up of the login page. If the decision of showing a login form
is moved out of start, there's no need for default_auth too. 

Gian

Re: [Phplib-users] again auth.inc and forms phpnuke like

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

> Masserelli(aka negro) and it's problem to solve was:
> 
> - If a page require that a user is authenticated, phplib auth it. And
>   was implemented the automated states that changes in order to cover
>   all problems related.
> 
> Watching Giancarlo Pinerolo patch, I think that you(Giancarlo) have not
> understood very well how Auth class work. It is all so simple. There is

I know it by heart. It's broken, both in logic and in usability.

The problem is that when  auth[uid] is 'form' it cannot be 'nobody' at
the same time. Why didn't we choose some other variable instead of
auth[uid] to hold that status?
I make you an example: You are in a non-nobody, non-authed (only
session) page, you visit a page that has full auth, your auth[uid] is
then set to 'form'. From this moment you cannot access anymore even
those pages that should be accessible to defaul_auth: case 3.
And don't tell me that the solution is to hit cancel_login. Maybe it's
better to use another status variable, eh?

> 
> There is a method in Auth class that was invented to do this:
> 
> >From now i'm referring to revision
> 
> $Id: auth.inc,v 1.7 2002/04/25 02:19:31 richardarcher Exp $
> 
> at line 289 the declaretion and comments of a method
> 
>   ## This method can authenticate a user before the loginform
>   ## is being displayed. If it does, it must set a valid uid
>   ## (i.e. nobody IS NOT a valid uid) just like auth_validatelogin,
>   ## else it shall return false.
> 
>   function auth_preauth() { return false; }
> 
> This method well implemented solve our problem in a clean and tidy way.

Yeah, not the way the rest of start does!

> My approach is intented to solve this problem in a standard phplib
> enviroment without patch nothing and reuse phplib structure.
> 
> Procedure to implement the form without automatic auth procedure:
> (auth->nobody attribute it intented to be true to use this method)
> 
> - First:
> 
> We need to modify a line in auth.inc, I propose this change to stable
> cvs tree.
> 
> at line 65 substitute with:
>     if ($this->is_authenticated() and $this->auth["uid"] != "nobody") {



> 
> - Second:
> 
> in local.inc override the method auth_preauth
> 
> class Trial_Auth extends Auth {
> ...
> ...
>   function auth_preauth() {
>     global $HTTP_POST_VARS, $HTTP_GET_VARS;
>     if((isset( $HTTP_POST_VARS["username"] ) &&
>         isset( $HTTP_POST_VARS["password"] )
>       ) ||
>       (
>         isset( $HTTP_GET_VARS["username"]  ) &&
>         isset( $HTTP_GET_VARS["password"]  )
>       )) {
> 
>       if($uid = $this->auth_validatelogin()) {

auth_validatelogin already does all the surmentioned checks, and returns
true/false. These are then useless.


>         $this->loginfail = false;
>         return $uid;
>       } else {
>         $this->loginfail = true;
>         return false;
>       }
>     }
>   }
> ...
> ...
> }
> 
> - Third:
> 
> use it. Make a page like what i attacched.
> 
> Summarizing how use the auth features:
> 
> if($auth->loginfail) {
>   to check if the login is went succesfully or not
> }
> 
> if( $auth->is_authenticated() &&
>     $auth->auth["uid"] != "nobody"
>   ) {
>   watch logoff link
> } else {
>   watch the form that post/get username and password
> }
> 
> EOF:)

Gian

[Phplib-users] again auth.inc and forms phpnuke like

[Matteo S. <sg...@sg...>]

I'm again about managing authentication like "phpnuke":

- a login form is displayed only when the user is not auth
- the form is hidden if the user is authenticated

The Auth Class was originally designed mainly by Massimiliano
Masserelli(aka negro) and it's problem to solve was:

- If a page require that a user is authenticated, phplib auth it. And
  was implemented the automated states that changes in order to cover
  all problems related.

Watching Giancarlo Pinerolo patch, I think that you(Giancarlo) have not
understood very well how Auth class work. It is all so simple. There is
no reason to rewrite all...

There is a method in Auth class that was invented to do this:

From now i'm referring to revision

$Id: auth.inc,v 1.7 2002/04/25 02:19:31 richardarcher Exp $

at line 289 the declaretion and comments of a method

  ## This method can authenticate a user before the loginform
  ## is being displayed. If it does, it must set a valid uid 
  ## (i.e. nobody IS NOT a valid uid) just like auth_validatelogin,
  ## else it shall return false.

  function auth_preauth() { return false; }

This method well implemented solve our problem in a clean and tidy way.
My approach is intented to solve this problem in a standard phplib
enviroment without patch nothing and reuse phplib structure.

Procedure to implement the form without automatic auth procedure:
(auth->nobody attribute it intented to be true to use this method)

- First:

We need to modify a line in auth.inc, I propose this change to stable
cvs tree.

at line 65 substitute with:
    if ($this->is_authenticated() and $this->auth["uid"] != "nobody") {

- Second:

in local.inc override the method auth_preauth

class Trial_Auth extends Auth {
...
...
  function auth_preauth() {
    global $HTTP_POST_VARS, $HTTP_GET_VARS;
    if((isset( $HTTP_POST_VARS["username"] ) &&
        isset( $HTTP_POST_VARS["password"] )
      ) ||
      (
        isset( $HTTP_GET_VARS["username"]  ) &&
        isset( $HTTP_GET_VARS["password"]  )
      )) {

      if($uid = $this->auth_validatelogin()) {
        $this->loginfail = false;
        return $uid;
      } else {
        $this->loginfail = true;
        return false;
      }
    }
  }
...
...
}

- Third:

use it. Make a page like what i attacched.

Summarizing how use the auth features:

if($auth->loginfail) {
  to check if the login is went succesfully or not
}

if( $auth->is_authenticated() &&
    $auth->auth["uid"] != "nobody"
  ) {
  watch logoff link
} else {
  watch the form that post/get username and password
}


EOF:)

This is my implementation.

Have Fun:)

Feedbacks are likely apreciated:)

Bye

Matteo

-- 
    Matteo Sgalaberni                  |     Web    : http://www.sgala.com
    --                                 |     E-Mail : ma...@sg...
    System and Application Engineer    |
-------------------------------------------------------------------------------

Re: [Phplib-users] auth[uid]=form/nobody

[Michele M. <mic...@es...>]

Yes i did, there isn't any problem with or without your patch

Michele

Giancarlo Pinerolo wrote:

>For the sake of playing, did anyone try to register himself with login
>name of 'form' or 'nobody'?
>
>I haven't, but it could be worth trying. 
>
>Gian
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
>_______________________________________________
>Phplib-users mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phplib-users
>  
>

-- 

-------------------------------------------------------
Michele Marcucci		ESTREMI srl
Advanced IT Consultant		Via Emilia 310
mic...@es...	40026 Imola (BO)
				Phone +39 0542 615 888
nic-hdl: MM901-ITNIC		Fax +39 0542 615 895
-------------------------------------------------------

[Phplib-users] auth[uid]=form/nobody

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

For the sake of playing, did anyone try to register himself with login
name of 'form' or 'nobody'?

I haven't, but it could be worth trying. 

Gian

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

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

Admin wrote:
> 
> Just for saying that functions like $perm->check() and
> $perm->have_perm() work fine with your patch.
> Good job.
> 
> |If you already are logged with 'user' permissions, and submit a login
> |for an 'admin', will it work?
> 
> Yes I try but it doesn't work, but it isn't a problem for me, infact if
> someone logged in, the login form is substituted by a logout link.
> 

You need a session->delete or what the heck session->destroy, before. 
Apart from that, did you check it with the various register_globals off,
php 4.2.1, etc?

Really I have no time for this, at the moment. 
I am in the uneasy position of having to shout around to 'advertise'
that big hole.. which is something I hate to do. 
That patch is for solely test purposes, don't use it for anything else.

Giancarlo



> Have fun
> 
> Michele Marcucci
> 
> Giancarlo Pinerolo wrote:
> 
> >Michele Marcucci wrote:
> >
> >
> >>With this patch all works fine, i finally reach my scope, i can include
> >>now a loginform anywhere i want in my index page and it doesn't seem a
> >>stand-alone page, like it was before.
> >>I'm not sure if this patch is foundamental for the scope but now works,
> >>so many thanks Giancarlo and a question:
> >>Can i have problem now with the rest of "standard" phplib function and
> >>features?
> >>
> >>
> >>
> >
> >The perm->check feature I have to fix, to return true/false instead of
> >showing perminvalid (which was absurd anyway, you'd want a
> >login/register form instead)
> >
> >In the end you will not do
> >$perm->check()
> >
> >but, same as for auth,
> >
> >if(!$perm->check())
> >   {
> >   $auth->auth_loginform();  # or $perm->perminvalid, if you prefer
> >   }
> >
> >But I'ven't tried that yet.
> >If you already are logged with 'user' permissions, and submit a login
> >for an 'admin', will it work?
> >I've to try.
> >
> >The rest should work, but I exhort you to try it very very well before.
> >
> >Also I haven't tried it with the latest phplib-stable from cvs, which I
> >myself recently commited.
> >The two shouldn't interfere, 'cause the patch I applied to cvs is
> >related to session.
> >But better try it. And thanks for the feedback
> >
> >
> >Giancarlo
> >
> >_______________________________________________________________
> >
> >Don't miss the 2002 Sprint PCS Application Developer's Conference
> >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> >
> >_______________________________________________
> >Phplib-users mailing list
> >Php...@li...
> >https://lists.sourceforge.net/lists/listinfo/phplib-users
> >
> >

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

[Admin <ad...@go...>]

Just for saying that functions like $perm->check() and 
$perm->have_perm() work fine with your patch.
Good job.

|If you already are logged with 'user' permissions, and submit a login
|for an 'admin', will it work?

Yes I try but it doesn't work, but it isn't a problem for me, infact if 
someone logged in, the login form is substituted by a logout link.

Have fun


Michele Marcucci


Giancarlo Pinerolo wrote:

>Michele Marcucci wrote:
>  
>
>>With this patch all works fine, i finally reach my scope, i can include
>>now a loginform anywhere i want in my index page and it doesn't seem a
>>stand-alone page, like it was before.
>>I'm not sure if this patch is foundamental for the scope but now works,
>>so many thanks Giancarlo and a question:
>>Can i have problem now with the rest of "standard" phplib function and
>>features?
>>
>>    
>>
>
>The perm->check feature I have to fix, to return true/false instead of
>showing perminvalid (which was absurd anyway, you'd want a
>login/register form instead)
>
>In the end you will not do
>$perm->check()
>
>but, same as for auth,
>
>if(!$perm->check())
>   {
>   $auth->auth_loginform();  # or $perm->perminvalid, if you prefer
>   }
>
>But I'ven't tried that yet.
>If you already are logged with 'user' permissions, and submit a login
>for an 'admin', will it work?
>I've to try.
>
>The rest should work, but I exhort you to try it very very well before.
>
>Also I haven't tried it with the latest phplib-stable from cvs, which I
>myself recently commited.
>The two shouldn't interfere, 'cause the patch I applied to cvs is
>related to session.
>But better try it. And thanks for the feedback
>
>
>Giancarlo
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
>_______________________________________________
>Phplib-users mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phplib-users
>  
>

[Phplib-users] err

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

with 'form', 'value form',  auth['form'], 
I always meant to write

$auth->auth['uid']='form'

in my previous msgs. But I think you know... ;-)

G

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

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

> 
> Ya. I too have adopted, this patch you show, for years, transmitted over
> from generation to generation of phplib ;-)
> 
> That's why I decided to cut short the whole stuff.
> Nevertheless, you can much more easily and cleanly
> place it back in my page.inc (the one in the patch 'simplifying auth'),
  ^^^^^^^^^^^^^^

I meant the auth['form']'value trigger

> as a prior/post trigger to the form exibit .

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

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

Giancarlo Pinerolo wrote:
> 
> Joe Stewart wrote:
> >
> > Another method that works without patching phplib is like this:
> >
> > if(isset($HTTP_POST_VARS['username'])) { // this would be present if a login is in progress
> >       $auth->auth["uid"]= "form"; // this is what auth seems to want
> >       $auth->start();
> > }
> >
> > $auth->login_if(!$perm->have_perm('user'));
> > Here is a simple example:
> >
> >    http://www.phpslash.org/index.php3?section_id=11
> >
> > have fun,

Ya. I too have adopted, this patch you show, for years, transmitted over
from generation to generation of phplib ;-)

That's why I decided to cut short the whole stuff.
Nevertheless, you can much more easily and cleanly 
place it back in my page.inc (the one in the patch 'simplifying auth'),
as a prior/post trigger to the form exibit . 

Gian

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

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

Joe Stewart wrote:
> 
> Another method that works without patching phplib is like this:
> 
> if(isset($HTTP_POST_VARS['username'])) { // this would be present if a login is in progress
>       $auth->auth["uid"]= "form"; // this is what auth seems to want
>       $auth->start();
> }
> 
> $auth->login_if(!$perm->have_perm('user'));
> 
> Here is the original post:
> 
>    http://marc.theaimsgroup.com/?l=phplib&m=99114081209404&w=2
> 
> Here is a simple example:
> 
>    http://www.phpslash.org/index.php3?section_id=11
> 
> have fun,

This code confirms that is common practice to smashe the very reason ot
the auth['form'] intermiediate status value: be assured that a form was
set 'before' input is accepted.

It osoletes keepeing that value and overrides it.
The 'form' value was supposed to be a prerequisite, something the code
needs to have *before*  considering any 'username' an 'password' input
fields.
The actual code logic is:
if there's form, see if there are the fields.
This does the reverse, if there's a field username, then force 'form'
and loop over start.

It simply checks for an existing input field 'username'. (If it  checks
for  'password' too, you can even smash the necessity of log/reg) 
Exactly as my auth does.
These lines of code show that people already chose to consider the whole
auth->start method, as it is, obsolete, comment.

Gian

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

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

Layne Weathers wrote:
> 
> > Layne Weathers wrote:
> > >
> > > > The perm->check feature I have to fix, to return
> > > > true/false instead of showing perminvalid (which was
> > > > absurd anyway, you'd want a login/register form instead)
> > >
> > > You don't have to 'fix' anything. That's exactly what
> > > $perm->have_perm() does. $perm->check() is a shortcut to test
> > > and then show perminvalid if have_perm() failed.
> > >
> > > No, it isn't absurd. The login/register form should be
> > > there if no valid $auth is in place. The perminvalid makes
> > > perfect sense if the user is already logged in and does not
> > > have permission to access the page. I assume that each user
> > > has only one user account,
> >
> > You can be wrong here
> 
> I think I can deal with being wrong.
> 
> However, even if users have multiple accounts, I believe there is a
> difference between the login/register page and the perminvalid page that
> explains the lack of permission and suggests that the user login at a higher
> level in the provided login form.
> 
> To my mind, the person who is logged in already needs to see why they can't
> access the page. In your multiple accounts scenario, the person logging in
> for the first time might very well want to see what perms are necessary to
> use the page so they can login at the correct level. In your scenario the
> two pages are very similar, but in my scenario they aren't.

But no. The permivalid action can set whatever error message in
$auth->auth[error], even with the explanation that the page had before
(your perms are user, you eed admin...), and show the loginform

> 
> In the end, I'm happy as long as I can get the functionality I want without
> entirely rewriting the class(es).

As you correctly pointed out to me, there's no need to rewrite anything
in perm, ($perm->have_perm('whatever') is alredy there.
Don't worry, I won't fix anything.

But when you write software, you know that is always a lot easyer to
make anything that's multiuser work as monouser, than vv. 
So 'not knowing 'how to read nor how to write...'  I choose that other
assumption.

Gian

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

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

Layne Weathers wrote:
> 
> > The perm->check feature I have to fix, to return true/false instead of
> > showing perminvalid (which was absurd anyway, you'd want a
> > login/register form instead)
> 
> You don't have to 'fix' anything. That's exactly what $perm->have_perm()
> does. $perm->check() is a shortcut to test and then show perminvalid if
> have_perm() failed.
> 
> No, it isn't absurd. The login/register form should be there if no valid
> $auth is in place. The perminvalid makes perfect sense if the user is
> already logged in and does not have permission to access the page. I assume
> that each user has only one user account,

I mean, there are two possibilities based on different assumptions.  
One will lead you  to something that cannot comprise the other
assumption 
The other will bring you to something that can comprise both
assumptions.
'Not knowing how to red nor how to write', we say here...which one do
you choose?
Unless there's a specific policy that prohibits having more than an
account...



Gian




 so showing them a login/register
> form is a waste of time.
> 
> It sounds like you need to tweak your perminvalid(). If there is a valid
> auth, then show them perminvalid, otherwise show them the login form.
> 
> Layne Weathers
> Ifworld Inc.
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users

RE: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

[Layne W. <la...@if...>]

> Layne Weathers wrote:
> >
> > > The perm->check feature I have to fix, to return
> > > true/false instead of showing perminvalid (which was
> > > absurd anyway, you'd want a login/register form instead)
> >
> > You don't have to 'fix' anything. That's exactly what
> > $perm->have_perm() does. $perm->check() is a shortcut to test
> > and then show perminvalid if have_perm() failed.
> >
> > No, it isn't absurd. The login/register form should be
> > there if no valid $auth is in place. The perminvalid makes
> > perfect sense if the user is already logged in and does not
> > have permission to access the page. I assume that each user
> > has only one user account,
>
> You can be wrong here

I think I can deal with being wrong.

However, even if users have multiple accounts, I believe there is a
difference between the login/register page and the perminvalid page that
explains the lack of permission and suggests that the user login at a higher
level in the provided login form.

To my mind, the person who is logged in already needs to see why they can't
access the page. In your multiple accounts scenario, the person logging in
for the first time might very well want to see what perms are necessary to
use the page so they can login at the correct level. In your scenario the
two pages are very similar, but in my scenario they aren't.

In the end, I'm happy as long as I can get the functionality I want without
entirely rewriting the class(es).

Layne Weathers
Ifworld Inc.

Re: [Phplib-users] Giancarlo Pinerolo (pingus) auth patch

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

Layne Weathers wrote:
> 
> > The perm->check feature I have to fix, to return true/false instead of
> > showing perminvalid (which was absurd anyway, you'd want a
> > login/register form instead)
> 
> You don't have to 'fix' anything. That's exactly what $perm->have_perm()
> does. $perm->check() is a shortcut to test and then show perminvalid if
> have_perm() failed.
> 
> No, it isn't absurd. The login/register form should be there if no valid
> $auth is in place. The perminvalid makes perfect sense if the user is
> already logged in and does not have permission to access the page. I assume
> that each user has only one user account,

You can be wrong here

Gian