Thread: [Phplib-users] again auth.inc and forms phpnuke like
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Matteo S. <sg...@sg...> - 2002-06-09 23:10:04
Attachments:
trial.php
|
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 |
-------------------------------------------------------------------------------
|
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 00:29:01
|
> 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
|
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 00:53:04
|
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 |
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 01:42:40
|
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
|
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 09:07:09
|
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 |
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 09:54:53
|
>
> 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
|
|
From: Guillaume D. <gde...@pr...> - 2002-06-10 10:33:05
|
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... |
|
From: Michael C. <mdc...@mi...> - 2002-06-10 13:23:33
|
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/ |
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 15:26:25
|
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 |
|
From: Matteo S. <sg...@sg...> - 2002-06-10 18:07:14
|
On Mon, Jun 10, 2002 at 05:22:39PM +0200, Giancarlo Pinerolo wrote: > > 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? IMHO actual phplib auth is correct and don't have all problems that you describe. If you want to mantain another auth mantain it by yourself. And who want to migrate to phpauth or whatever is free to do this. Don't touch phplib auth.inc. > 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. You think a lot of things. First read http://www.kill-9.it/guido/rfc1855.txt. Your quoting is awfull. > 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. It probably works fine, but IMHO it is very dirty coded. > But it's all 'a debatre', to be discussed. The answer to this debate IMHO is in an italian way: "anche no". Sincerly Matteo -- Matteo Sgalaberni | Web : http://www.sgala.com -- | E-Mail : ma...@sg... System and Application Engineer | ------------------------------------------------------------------------------- |
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 20:45:13
|
Matteo Sgalaberni wrote: > IMHO actual phplib auth is correct and don't have all problems that > you describe. If you want to mantain another auth mantain it by > yourself. The problem is that in the last years most of the activity of the maintainers of phplib has been to 'handle out' workarounds and unsupported patchess on these topics: login forms within pages, cancel_login, auth_nobody, back button not possible, etc. And everytime I said: there is some rot behind that we'd better fix once for all. If for you is OK you can guard you copy of phplib, and keep on using it. Me, I already started to give up on passing patches to something I know is broken. Giancarlo |
|
From: Michael C. <mdc...@mi...> - 2002-06-11 01:47:44
|
On Mon, Jun 10, 2002 at 05:22:39PM +0200, Giancarlo Pinerolo wrote: > You mean we should integrate it into phplib? Or that we should migrate > to phpauth? Whatever you want to do. It's all GPL'd. > 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. Name one. There are no features missing that I use (and plenty of features that I've added that are needed in phplib), but some people may want templates. It should be possible to bring the code over with no changes. > 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. Given that phplib's auth is broken, I don't care to make a drop-in replacement. Some of the problems are fundamental to its design, such as the following mess: if ($auth && $auth->is_authenticated() && $auth->is_authenticated()!='form') ... I would rather *not* emulate that. I also want to get away from including tons of files, I'd rather just call functions since you don't have the confusing scoping issues that file inclusion may bring. I could go on, but you get the point. I cover most of this in my docs, anyway, read them to understand most of the issues behind the divergence from phplib's auth class. Michael -- Michael Darrin Chaney mdc...@mi... http://www.michaelchaney.com/ |
|
From: Tarique S. <ta...@sa...> - 2002-06-11 08:46:32
|
On Mon, 10 Jun 2002, Michael Chaney wrote: > On Mon, Jun 10, 2002 at 05:22:39PM +0200, Giancarlo Pinerolo wrote: > > You mean we should integrate it into phplib? Or that we should migrate > > to phpauth? > > Whatever you want to do. It's all GPL'd. I am sure you meant LGPL'd ? else it would be not possible to use it in commercial projects Tarique -- ============================================================= PHP Applications for E-Biz: http://www.sanisoft.com Indian PHP User Group: http://groups.yahoo.com/group/in-phpug ============================================================= |
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 14:15:49
|
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 |
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 08:35:38
|
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. |
|
From: Giancarlo P. <gia...@na...> - 2002-06-10 08:55:02
|
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 |
Thanks for helping keep SourceForge clean.
X