Thread: [Phplib-users] on auth
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Giancarlo <gia...@na...> - 2002-09-24 22:39:08
|
May I recall Kristian Kohentopp's comments about actual auth oddities? http://sourceforge.net/mailarchive/forum.php?thread_id=875358&forum_id=808 <snip> >- what is > the use of the auth['uid']='form' status, if not better > security? Koehntopp PHPLIB was programmed with interstitial (blocking) authentication in mind. The state machine is really only useful for that, and little else. Default Auth and auth_preauth() were added as an afterthought in Koehntopp PHPLIB, and are really cluttering up the Auth process. The whole thing should be redesigned, and using a sidebar login and default authentication as the main model, as this is much more common and useful than the original interstitial auth. </snip> Has anyone tried my new auth at http://sourceforge.net/tracker/index.php?func=detail&aid=561500&group_id=31885&atid=403613 Sorry to insist anyway, but that would solve many problems, and is perfectly compatible. Gian |
|
From: Chris J. <ch...@ch...> - 2002-09-25 03:26:14
|
On Wed, Sep 25, 2002 at 12:34:46AM +0200, Giancarlo wrote: > May I recall Kristian Kohentopp's comments about actual auth oddities? > http://sourceforge.net/mailarchive/forum.php?thread_id=875358&forum_id=808 > > <snip> > > >- what is > > the use of the auth['uid']='form' status, if not better > > security? > > Koehntopp PHPLIB was programmed with interstitial (blocking) > authentication in mind. The state machine is > really only useful > for that, and little else. Default Auth and > auth_preauth() were added as an afterthought in Koehntopp PHPLIB, and are > really cluttering up the Auth process. > The whole thing should be redesigned, and using a > sidebar login and default authentication as the main model, as > this is much more common and useful than the original interstitial auth. > > </snip> > > > Has anyone tried my new auth at > http://sourceforge.net/tracker/index.php?func=detail&aid=561500&group_id=31885&atid=403613 > > Sorry to insist anyway, but that would solve many problems, and is perfectly > compatible. > > Gian I have not tried your new auth, Gian. If it implements Kristian's suggestion for the redesigned Auth process for sidebar and default authentication, then I think it would be great to offer PHPLIB users the choice of the old, interstitial (blocking) Auth method, and your new default Auth method. I currently have a large application which uses the old blocking Auth method and it is the right thing for that application -- all users must be authenticated and there are no default facilities. But the default auth model is more common, as Kristian pointed out above. -- ..chris |
|
From: Matteo S. <sg...@sg...> - 2002-09-25 07:24:46
|
On Tue, Sep 24, 2002 at 10:43:11PM -0500, Chris Johnson wrote:
> authentication, then I think it would be great to offer PHPLIB users
> the choice of the old, interstitial (blocking) Auth method, and your
I agree with you.
> I currently have a large application which uses the old blocking Auth
And with you a lot of people that use PHPLIB from years and have
invested a lot of time and money in application that are based on
this...
> method and it is the right thing for that application -- all users must
> be authenticated and there are no default facilities.
Yeah!:)
Bay
Matteo
--
Matteo Sgalaberni | Web : http://www.sgala.com
-- | E-Mail : ma...@sg...
System and Application Engineer |
-------------------------------------------------------------------------------
|
|
From: Giancarlo <gia...@na...> - 2002-09-25 08:15:40
|
Il 09:24, mercoled=EC 25 settembre 2002, Matteo Sgalaberni ha scritto: > On Tue, Sep 24, 2002 at 10:43:11PM -0500, Chris Johnson wrote: > > authentication, then I think it would be great to offer PHPLIB users > > the choice of the old, interstitial (blocking) Auth method, and your > > I agree with you. To be clear: that auth can behaves EXACTLY as before, with no changes to= the=20 code. You can drop it in as a replacemet.=20 OR you can use it the other way (with the deferred form behaviour), like= the=20 default_auth. Then you have to chage your code. Gian |
|
From: Dr T. S. <ta...@sa...> - 2002-09-25 08:26:54
|
On Wed, 25 Sep 2002, Giancarlo wrote: > Il 09:24, mercoled=EC 25 settembre 2002, Matteo Sgalaberni ha scritto: > > On Tue, Sep 24, 2002 at 10:43:11PM -0500, Chris Johnson wrote: > > > authentication, then I think it would be great to offer PHPLIB users > > > the choice of the old, interstitial (blocking) Auth method, and your > > > > I agree with you. >=20 > To be clear: that auth can behaves EXACTLY as before, with no changes to= the=20 > code. You can drop it in as a replacemet.=20 Yes - this works very well - did some work around with your class Good work!!! Cheers Tarique=20 --=20 =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=3D=3D=3D=3D=3D PHP Applications for E-Biz: http://www.sanisoft.com Indian PHP User Group: http://groups.yahoo.com/group/in-phpug =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=3D=3D=3D=3D=3D |
|
From: Giancarlo <gia...@na...> - 2002-09-25 07:26:19
|
Il 05:43, mercoled=EC 25 settembre 2002, hai scritto: > I have not tried your new auth, Gian. If it implements Kristian's > suggestion for the redesigned Auth process for sidebar and default > authentication, then I think it would be great to offer PHPLIB users > the choice of the old, interstitial (blocking) Auth method, and your > new default Auth method. Interstitial (blocking) mode and default_auth (nobody) are conceptually = two=20 different, separate things. The relation among the two is the fact that phplib, whenever has shown a=20 login page, wants to have auth[uid]=3D'form' before accepting its submis= sion. And, to decide if the login form has to be shown or not, some auth class = has=20 to be instantiated, even if not already logged: so the need to default_au= th. The interstitial (blocking) method is something more than just showing a=20 'spalsh login page' instead of a form somewhere down.=20 The interstitial concept is that, once you have requested a protected pag= e=20 and you are not authenticated , you session enters a blocking state=20 (auth[uid]=3Dform). You have a single point of entrance into the session.= You=20 have to request a ticket (uid=3Dform) before you can proceed with the ses= sio.=20 Your session is blocked, everywhere, on other frames, in going 'back', in= a=20 new browser window. The aim of the 'form' status is to be sure that you have previously reque= sted=20 a login form to phplib before submitting it. Is to prevent people registe= ring=20 with a single POST, without having entered the 'form' status before. > > I currently have a large application which uses the old blocking Auth > method and it is the right thing for that application -- all users must > be authenticated and there are no default facilities. This is different that interstitial method. You mayy have 'no default=20 facilities' even without interstitial blocking mode. Gian |
|
From: Giancarlo <gia...@na...> - 2002-09-25 08:02:29
|
Il 05:43, mercoled=EC 25 settembre 2002, hai scritto: > > I currently have a large application which uses the old blocking Auth > method and it is the right thing for that application -- all users must > be authenticated and there are no default facilities. > Then what you want is: wherever I instantiate the auth feature, if the user bears no authenticat= ion,=20 a splash login page is shown by auth itself, your script does not have to= =20 check anything. Just instantiating the auth class will do it. You don't=20 really want blocking mode. You wat a splash form behaviour handled by aut= h=20 itself. Others, or you in other apps, my want: whenever I instantiate the auth feature, auth returns me a value that say= s if=20 the user bears authentication or not. And my script, not auth, decides wh= at=20 to do, when to do it. You don't want blocking mode here either. You want = to=20 handle the situation by yourself knowing if the user is logged or not. Th= a=20 auths class outputs nothing, it just returns you a value that says if he = is=20 logged in or not They are two different things, but they eat the tail one each other, as i= t is=20 now. My auth class, with the splashform behaviour, suits your need perfectly t= he=20 same as before.=20 The 'form' aim (preveting registration with a single POST, maybe from a b= atch=20 script), is not needed once we are sure, for example, that a new session = can=20 be obtained by simply appending ?Example_session=3Dfoo to the URL request= . The=20 effect is the same as that of having previously requested a login form:=20 prevents single POST registration Gian |
|
From: Giancarlo <gia...@na...> - 2002-09-25 08:07:23
|
Il 09:58, mercoled=EC 25 settembre 2002, I wrote:
Oops:
> My auth class, with the splashform behaviour, suits your need perfectly=
the
> same as before.
> The 'form' aim (preveting registration with a single POST, maybe from a
> batch script), is not needed once we are sure, for example, that a new
> session can be obtained by simply appending ?Example_session=3Dfoo to t=
he URL
^^^
can NOT
gian
|
|
From: Chris J. <ch...@ch...> - 2002-09-25 17:30:26
|
On Wed, Sep 25, 2002 at 09:58:07AM +0200, Giancarlo wrote:
> Il 05:43, mercoledì 25 settembre 2002, hai scritto:
> >
> > I currently have a large application which uses the old blocking Auth
> > method and it is the right thing for that application -- all users must
> > be authenticated and there are no default facilities.
> >
>
> Then what you want is:
> wherever I instantiate the auth feature, if the user bears no authentication,
> a splash login page is shown by auth itself, your script does not have to
> check anything. Just instantiating the auth class will do it. You don't
> really want blocking mode. You wat a splash form behaviour handled by auth
> itself.
>
> Others, or you in other apps, my want:
>
> whenever I instantiate the auth feature, auth returns me a value that says if
> the user bears authentication or not. And my script, not auth, decides what
> to do, when to do it. You don't want blocking mode here either. You want to
> handle the situation by yourself knowing if the user is logged or not. Tha
> auths class outputs nothing, it just returns you a value that says if he is
> logged in or not
>
> They are two different things, but they eat the tail one each other, as it is
> now.
>
> My auth class, with the splashform behaviour, suits your need perfectly the
> same as before.
> The 'form' aim (preveting registration with a single POST, maybe from a batch
> script), is not needed once we are sure, for example, that a new session can
> be obtained by simply appending ?Example_session=foo to the URL request. The
> effect is the same as that of having previously requested a login form:
> prevents single POST registration
>
>
> Gian
So, Gian, are you saying that your new Auth class provides both behaviors,
but that your "splash login page" although it looks the same to the
user, it is distinctly functionally different from the current PHPLIB
blocking method?
I'm having a hard time understanding. I don't want users to be able
to see ANY protected page without logging in, and ALL of my pages are
protected pages. The way it works now using the PHPLIB blocking method,
all I have to do is call page_open() and it is assured that they are
blocked until they have logged in and gotten a session ID in a cookie
(fallback to GET). Does your "splash form" behavior in your new Auth
do that?
Thanks!
--
..chris
|
|
From: Giancarlo <gia...@na...> - 2002-09-25 18:56:57
|
Il 19:30, mercoled=EC 25 settembre 2002, Chris Johnson ha scritto: > > So, Gian, are you saying that your new Auth class provides both behavio= rs, > but that your "splash login page" although it looks the same to the > user, it is distinctly functionally different from the current PHPLIB > blocking method? By blocking mode, interstitial mode, we are not talking about access, or=20 blocking access. We are talking about blocking the authentication process, in a 'login_in=20 progress' state,=20 or, more clear, 'we_have_sent_the_form_and_expect_loginfields', so the=20 session is blocked until we get the cancel_login Effects:=20 -If you had just visited an unprotected page, you can't click 'back', you= =20 need to press cancel_login. -If you open an unpreotected page in a new browser window you get the log= in=20 form,=20 -etc because you presistent session it has an $auth object in it, with=20 auth[uid]=3D"form", that is you are not logged on, but you have the auth = object=20 to either clear or fully start. > > I'm having a hard time understanding. I don't want users to be able > to see ANY protected page without logging in, and ALL of my pages are > protected pages. The way it works now using the PHPLIB blocking method= , > all I have to do is call page_open() and it is assured that they are > blocked until they have logged in and gotten a session ID in a cookie > (fallback to GET). Does your "splash form" behavior in your new Auth > do that? yes, access blocking is same as before. Gian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X