Thread: [Phplib-users] auth_registerform/auth_doregister -- why?
Brought to you by:
nhruby,
richardarcher
From: Aric C. <gre...@pe...> - 2002-09-24 17:31:00
|
Maybe I'm missing something. But I dont see why the auth_registerform() = and auth_doregister() functions are there. If you set the mode to reg = you get these functions and if its set to log you get auth_loginform() = and auth_validatelogin(). Why have these four functions? If you want a = registration form, just put it in auth_loginform() and have = auth_validatelogin() do the user creation stuff. I dont see the = difference. What am I missing here? |
From: Joe S. <jo...@be...> - 2002-09-24 19:19:43
|
Hi Aric, On Tue, Sep 24, 2002 at 10:30:43AM -0700, Aric Caley wrote: > Maybe I'm missing something. But I dont see why the auth_registerform() and > auth_doregister() functions are there. If you set the mode to reg you > get these functions and if its set to log you get auth_loginform() and > auth_validatelogin(). Why have these four functions? If you want a > registration form, just put it in auth_loginform() and have > auth_validatelogin() do the user creation stuff. I dont see the > difference. What am I missing here? I like the flexibility in the library for this. I need a registration form that gathers more information than the login form requires for authentication. |
From: Aric C. <gre...@pe...> - 2002-09-24 19:31:38
|
But if you have to implement the form anyway, who cares what the function is called? Implement the form you want. Now, if the login form normaly came up and then gave you an option to go to the registration form then I could see a reason to have the two functions for forms and two functions for validation. But it doesnt seem to work like that. At least I can't get it to do that. You either *always* get registerform()/doregister() or *always* get loginform()/validatelogin() depending on the mode. The mode never changes. So one set of functions never gets called. So why have two? What am I missing? ----- Original Message ----- From: "Joe Stewart" <jo...@be...> To: "phpplib" <php...@li...> Sent: Tuesday, September 24, 2002 12:18 PM Subject: Re: [Phplib-users] auth_registerform/auth_doregister -- why? > Hi Aric, > > On Tue, Sep 24, 2002 at 10:30:43AM -0700, Aric Caley wrote: > > Maybe I'm missing something. But I dont see why the auth_registerform() and > > auth_doregister() functions are there. If you set the mode to reg you > > get these functions and if its set to log you get auth_loginform() and > > auth_validatelogin(). Why have these four functions? If you want a > > registration form, just put it in auth_loginform() and have > > auth_validatelogin() do the user creation stuff. I dont see the > > difference. What am I missing here? > > I like the flexibility in the library for this. I need a registration > form that gathers more information than the login form requires for > authentication. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > |
From: Joe S. <jo...@be...> - 2002-09-24 19:37:53
|
On Tue, Sep 24, 2002 at 12:31:19PM -0700, Aric Caley wrote: > But if you have to implement the form anyway, who cares what the function is > called? Implement the form you want. > > Now, if the login form normaly came up and then gave you an option to go to > the registration form then I could see a reason to have the two functions > for forms and two functions for validation. But it doesnt seem to work like > that. At least I can't get it to do that. > Ah, It can work that way just fine. > You either *always* get registerform()/doregister() or *always* get > loginform()/validatelogin() depending on the mode. The mode never changes. > So one set of functions never gets called. So why have two? What am I > missing? > It's a logic problem that the mode never changes not auth.inc. I just got burned on that with register_globals off. ( cvs commit soon for phpslash). Look at current cvs of phpSlash for an example of working code. Joe |
From: Aric C. <gre...@pe...> - 2002-09-24 20:05:20
|
----- Original Message ----- From: "Joe Stewart" <jo...@be...> To: "phpplib" <php...@li...> Sent: Tuesday, September 24, 2002 12:36 PM Subject: Re: [Phplib-users] auth_registerform/auth_doregister -- why? > On Tue, Sep 24, 2002 at 12:31:19PM -0700, Aric Caley wrote: > > But if you have to implement the form anyway, who cares what the function is > > called? Implement the form you want. > > > > Now, if the login form normaly came up and then gave you an option to go to > > the registration form then I could see a reason to have the two functions > > for forms and two functions for validation. But it doesnt seem to work like > > that. At least I can't get it to do that. > > > > Ah, It can work that way just fine. Oh, good... that makes sense... that is cool... I just dont know how to do it.. > > You either *always* get registerform()/doregister() or *always* get > > loginform()/validatelogin() depending on the mode. The mode never changes. > > So one set of functions never gets called. So why have two? What am I > > missing? > > > > It's a logic problem that the mode never changes not auth.inc. I just got > burned on that with register_globals off. ( cvs commit soon for phpslash). I'm not sure what you mean... > Look at current cvs of phpSlash for an example of working code. that was going to be my next move. :) Haven't looked at recent code as I've been working on something else. Have you added user registrations yet? |
From: Joe S. <jo...@be...> - 2002-09-24 20:25:08
|
On Tue, Sep 24, 2002 at 01:05:03PM -0700, Aric Caley wrote: > > > > > It's a logic problem that the mode never changes not auth.inc. I just got > > burned on that with register_globals off. ( cvs commit soon for > phpslash). > > I'm not sure what you mean... > If you change the mode in the class definition, you get the resulting mode's form. So Auth is working in this regard. The mode just needs to change depending on the GET variable as well. An example - In your constructor of the class that extends Auth if ($HTTP_GET_VARS['mode']=='reg') { $this->mode='reg'; } else { $this->mode='log'; } This should bring up the registration form if mode=reg in the url. > > Look at current cvs of phpSlash for an example of working code. > > that was going to be my next move. :) Haven't looked at recent code as > I've been working on something else. Have you added user registrations yet? Yeah, The current cvs has some other changes that aren't completed so don't use it in production yet. |
From: Giancarlo <gia...@na...> - 2002-09-24 21:05:28
|
Il 21:36, marted=EC 24 settembre 2002, hai scritto: > On Tue, Sep 24, 2002 at 12:31:19PM -0700, Aric Caley wrote: > > But if you have to implement the form anyway, who cares what the func= tion > > is called? Implement the form you want. > > > > Now, if the login form normaly came up and then gave you an option to= go > > to the registration form then I could see a reason to have the two > > functions for forms and two functions for validation. But it doesnt = seem > > to work like that. At least I can't get it to do that. > > Ah, It can work that way just fine. > > > You either *always* get registerform()/doregister() or *always* get > > loginform()/validatelogin() depending on the mode. The mode never > > changes. So one set of functions never gets called. So why have two?= =20 > > What am I missing? You are wrong. The script changes $this->mode somewhere, for it's tempora= ry=20 use! Can't remember where. This is one of the oddities of this all. In my auth path I made (long time ago, but I exhort you to consider it) i= t be=20 decided SOLELY by the get parameter. =2E Gian |
From: Giancarlo <gia...@na...> - 2002-09-25 21:27:46
|
;-)) > However, I've lost all interstitial auth/perm. I know you explained this, > but I don't find it workable. This word, interstitial, is becoming popular. Remembers me the dentist. What do you men here for 'i?ve lost all interstitial auth/perm ? An interstice is a narrow passage, isn't it? An interstite is something so narrow, that you can pass through only one by one. So i suppose that by 'interstitial' we were speaking about the login_in_progress blocking state. Where you need a cancel login to get free of a there-but-not-yet-born auth object in session > > Using different include/require files for parts the application doesn't > sit well. > > I use the interstitial checks to prompt a login for such things as admin And what is intersitial check? > One feature needed for interstitial use is the preservation of GET and > POST variables. Preservation of get post variables, yes. I got this. The splashform model is needed if you want to direct someone to a URL with GET (I am not sure POST too) parameters that auth will intercept,, show a login form if needed, an pass on to the page that was originally requested. I think this can be done only with the splashform behaviour. It works like that already, as auth did. You point a link to a protected page, and phplib splases the login form, and after you successfully login you are taken to the real page. All these have the same url, so get and maybe post data too can be carried through this login process Anyway with my auth, a page that contains a form that points to a login/register page can be well without auth class, or an auth class and deferred form behaviour (visible, with different contents, by both suthed an unauthed users, as default_auth) > This can be done by registering them in auth_loginform() > and restoring in auth_validatelogin() but would be much more elegant > designed into auth. > > Joe |