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

[Phplib-users] Re: latest snapshot

[Marko K. <M.K...@os...>]

Hi,

shouldn't we in general use the $_POST, $_GET vars from now on, instead of
the old $HTTP_* variables? The latter one don't seem to be recommended for
further use and if a new phplib4 is created one should use right away the
proper superglobals.

Marko

RE: [Phplib-users] Patch to page.inc

[Marko K. <M.K...@os...>]

On Thu, 31 Oct 2002, Rob Hutton wrote:

> OK, I'm not a regex guy, so the goals are to strip the
> $this->urlaction, the =value that follows, anf the preceeding & if it
> is there
that's what is done by

 <?php
     $a='url?test=testen&&test2=test2en&';
     echo "Rewrote:".ereg_replace("([?&])test=[^&]*&*", "\\1",$a)."\n";

 ?>

>(it may be the first parameter and therefor is preceded by a
> ? which should be left unless it is the only parameter).
could be done with

 <?php
     $a='url?&';
     echo "\nNew: ".ereg_replace("^([^&?]*)[?&]+$", "\\1",$a)."\n";
 ?>

which removes all &s and ?s from the end of the string!

Marko

[Phplib-users] RE: Another regex expression

[Rob H. <rob...@ws...>]

Sorry, small correction (as in it does not work like this!!!), the last
[&|$] should be (&|$)

Thanks,

> -----Original Message-----
> From: Rob Hutton [mailto:rob...@ws...]
> Sent: Sunday, November 03, 2002 7:50 PM
> To: Phplib-Users
> Subject: Another regex expression
>
>
> I continue to have problems with the Regex in the current
> login_if (not supported under javascript, does not work if the
> parameter passed with $this->urlaction has numbers in it, etc.).
> Here is one that I think is working.  Please try it out...
>
>
> ([?&]*)authcmd=(.)*[&|$]
>
> This also prevents the multiple &&&&
>
> Rob Hutton
> Web Safe
> www.wsafe.com
>
>

[Phplib-users] Another regex expression

[Rob H. <rob...@ws...>]

I continue to have problems with the Regex in the current login_if (not
supported under javascript, does not work if the parameter passed with
$this->urlaction has numbers in it, etc.).  Here is one that I think is
working.  Please try it out...


([?&]*)authcmd=(.)*[&|$]

This also prevents the multiple &&&&

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271

Re: [Phplib-users] three tier auth made possible

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

> or return false.  This all works with the auth example that I sent without

Why don't you post it somewhere at the project (I used the patches area on 
sourceforge), so we can all find it and you can update it for all and we get 
notified?

Thanks!

Gian

Re: [Phplib-users] three tier auth made possible

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

Il 05:34, sabato 2 novembre 2002, Rob Hutton ha scritto:
>   But, again, you are mixing auth into page.  All of this could be done in
> the auth_handlelogin().  From site B, it would be local.  From site A,
> auth_validatelogin would take the information gathered from the login form
> and validate it through XMLRPC with site A and either return the valid UID
> or return false. 


yes yes, there is more than one way to do it ;-)

Don't worry, I'd manage that somehow, no matter how things are distributed, 
the mportant is that auth now is clear and understandable in its inherent 
simplicity.


Gian 

Re: [Phplib-users] three tier auth made possible

[Dr T. S. <ta...@sa...>]

On Fri, 1 Nov 2002, Giancarlo wrote:

> BTW, this went into nowhere for some other reason, but when I did the 
> analysis I thought to adapt phplib + XMLRPC for it and made, I think, a good 
> design, that unfortunately was never payed to me ;-(

Remote XMLRPC/SOAP auth with PHPlib would be a great idea - how about
making it a separate auth class?

That would be a more logical design... ...

Tarique
-- 
=============================================================
PHP Applications for E-Biz: http://www.sanisoft.com

Indian PHP User Group: http://groups.yahoo.com/group/in-phpug
=============================================================

RE: [Phplib-users] three tier auth made possible

[Rob H. <rob...@ws...>]

  But, again, you are mixing auth into page.  All of this could be done in
the auth_handlelogin().  From site B, it would be local.  From site A,
auth_validatelogin would take the information gathered from the login form
and validate it through XMLRPC with site A and either return the valid UID
or return false.  This all works with the auth example that I sent without
mixing auth logic into page.  Which BTW you may not even be using auth with.
You may just be storing session variables...

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Friday, November 01, 2002 10:59 AM
> To: rob...@ws...; phplib-users
> Subject: Re: [Phplib-users] three tier auth made possible
>
>
> ...
> >   Secondly, your example would be addressed in two parts I
> would guess.  A
> > auth_preauth function would be written that runs in start so
> that when you
> > browsed to site A or B, the other was queried through an XMLRPC
> interface
> > to see if you were already authenticated there, and if so,
> would give you
> > the same level of access.  If you were not, then (assuming
> blocking and not
> > default auth) if that failed it would show the login screen.
>
> Well, I chose page.inc because it can act as the 'middle tier'.
> It can call
> the local auth, the one within its same class, or the remote.
> There can be many cases:
> a) The simplest one is that Site A registers at Site B, and only Site B
> performs the authentication. In this case you could register to Site B
> directly, or by entering the info at Site A, but the
> authentication is done
> always by Site B.  It could make sense that Site A would pull
> down locally,
> and consolidate locally, some info for all his users that are
> registered at
> Site B, with some extra info pertaining only to his site activity.
> b) A second case, that I see problematic, would be that one could
> either be
> registered at Site A or at Site B. In this case Site A would need
> to query
> Site B and vv, to see if the user is registered there, if not here.
>
> So, for case a:
> on Site A, page.inc is an  HTML page handler, checks GET/POST
> vars, calls
> its own auth that perform an XMLRPC call to Site B.
> On Site B the request is handled by an XML page.inc handler,
> which calls its
> local auth methods that rely on the local db, and this XML
> page.inc replies
> in XML data to Site A.
>
> On Site B there can be also an HTML page.inc handler, that would
> manage local
> requests coming from their own site,, so all locally.
>
> > auth_handlelogin would take the results returned from the login
> form, check
> > it's local auth storage mechanism, check the other site through
> XMLRPC, and
> > if either one was successful, return the uid.  All of this with
> no logic in
> > page at all.
> >   As far as cross site registration, propagating information
> from one DB to
> > another is much better accomplished at the DB level.  Otherwise
> you end up
>
> This openss up a series of problems as granting the access to the
> DB to the
> network. I see better an XML/SOAP/XXX interface for this. Dbs are
> commonly
> deeply buried on dedicated boxes inside firewalls.
>
>
> All these things cannot be accomplished with a single method call, as
> $auth->start. We need to be able to ask some specific service to auth:
> authenticate/login/register. This does not mean that we won't
> need to be able
> to call a single method, but that makes sense only when both the
> middle tier
> and the auth tier are on the same machine.
>
> > with problems like Site A was not Available at the time that site B
> > disabled an account.  Better yet, do centralized auth.  This is the
> > Internet.  Or are you saying that site B is the centralized auth source.
>
> The one application I was asked this for was like this: an B2B web
> application that could either be installed in an intranet or on
> the web. That
> would be multi customer, that means it could be configured to
> serve different
> companies. Each company had his users, at various levels (admins,
> operators
> etc). Admins for example could personalize stuff and add users to their
> company's group. Then the application would contact a centralized
> site that
> provided some business information on firms and products, on a pay basis.
> Each company that uses this app would have the possibility to
> download and
> keep in the db for his slice of application, on a pay basis, some
> precious
> list of products/producers/contacts tailored to their needs, from
> the mother
> site (Site B). So single users were registered locally, but belonged to a
> determinate client company, which in all had some access to the
> centralized
> DB of precious contacts, and the amount of data downloaded would
> be accounted
> and payed for by volume by the client company in all, not by the
> single user.
> With this info, the application provided a mean to open multiple online
> negotiations on  preventives with the furnishing firms/contacts, and keep
> track of each negotiation for historic analysis. The whole
> business was that
> Site B, the mother site, would help fashion firms enter in contact with
> selected producers by building a virtual marketplace for them, and by
> selingg them the contacts and this service itself.
>
> BTW, this went into nowhere for some other reason, but when I did the
> analysis I thought to adapt phplib + XMLRPC for it and made, I
> think, a good
> design, that unfortunately was never payed to me ;-(
>
> Gian
>

[Phplib-users] of_text problem

[Rob H. <rob...@ws...>]

In the self_get_js function of of_text, there is a line that looks like

        $flags = ($this->icase ? "gi" : "g");

while the variable is defined as valid_icase at the top. The documentation
is consistent with the code, but I would recommend that the code be changed
to match the variable definition.

Rob Hutton
Web Safe
www.wsafe.com

Re: [Phplib-users] three tier auth made possible

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

...
>   Secondly, your example would be addressed in two parts I would guess.  A
> auth_preauth function would be written that runs in start so that when you
> browsed to site A or B, the other was queried through an XMLRPC interface
> to see if you were already authenticated there, and if so, would give you
> the same level of access.  If you were not, then (assuming blocking and not
> default auth) if that failed it would show the login screen.

Well, I chose page.inc because it can act as the 'middle tier'. It can call 
the local auth, the one within its same class, or the remote.
There can be many cases: 
a) The simplest one is that Site A registers at Site B, and only Site B 
performs the authentication. In this case you could register to Site B 
directly, or by entering the info at Site A, but the authentication is done 
always by Site B.  It could make sense that Site A would pull down locally, 
and consolidate locally, some info for all his users that are registered at 
Site B, with some extra info pertaining only to his site activity.
b) A second case, that I see problematic, would be that one could either be 
registered at Site A or at Site B. In this case Site A would need to query 
Site B and vv, to see if the user is registered there, if not here.

So, for case a:
on Site A, page.inc is an  HTML page handler, checks GET/POST vars, calls  
its own auth that perform an XMLRPC call to Site B. 
On Site B the request is handled by an XML page.inc handler, which calls its 
local auth methods that rely on the local db, and this XML page.inc replies 
in XML data to Site A.

On Site B there can be also an HTML page.inc handler, that would manage local 
requests coming from their own site,, so all locally.

> auth_handlelogin would take the results returned from the login form, check
> it's local auth storage mechanism, check the other site through XMLRPC, and
> if either one was successful, return the uid.  All of this with no logic in
> page at all.
>   As far as cross site registration, propagating information from one DB to
> another is much better accomplished at the DB level.  Otherwise you end up

This openss up a series of problems as granting the access to the DB to the 
network. I see better an XML/SOAP/XXX interface for this. Dbs are commonly 
deeply buried on dedicated boxes inside firewalls.


All these things cannot be accomplished with a single method call, as 
$auth->start. We need to be able to ask some specific service to auth: 
authenticate/login/register. This does not mean that we won't need to be able 
to call a single method, but that makes sense only when both the middle tier 
and the auth tier are on the same machine.

> with problems like Site A was not Available at the time that site B
> disabled an account.  Better yet, do centralized auth.  This is the
> Internet.  Or are you saying that site B is the centralized auth source.

The one application I was asked this for was like this: an B2B web 
application that could either be installed in an intranet or on the web. That 
would be multi customer, that means it could be configured to serve different 
companies. Each company had his users, at various levels (admins, operators 
etc). Admins for example could personalize stuff and add users to their 
company's group. Then the application would contact a centralized site that 
provided some business information on firms and products, on a pay basis. 
Each company that uses this app would have the possibility to download and 
keep in the db for his slice of application, on a pay basis, some precious 
list of products/producers/contacts tailored to their needs, from the mother 
site (Site B). So single users were registered locally, but belonged to a 
determinate client company, which in all had some access to the centralized 
DB of precious contacts, and the amount of data downloaded would be accounted 
and payed for by volume by the client company in all, not by the single user. 
With this info, the application provided a mean to open multiple online 
negotiations on  preventives with the furnishing firms/contacts, and keep 
track of each negotiation for historic analysis. The whole business was that 
Site B, the mother site, would help fashion firms enter in contact with 
selected producers by building a virtual marketplace for them, and by 
selingg them the contacts and this service itself.

BTW, this went into nowhere for some other reason, but when I did the 
analysis I thought to adapt phplib + XMLRPC for it and made, I think, a good 
design, that unfortunately was never payed to me ;-(

Gian

Re: [Phplib-users] auth url question

[Joe S. <jo...@be...>]

On Wed, Oct 30, 2002 at 09:26:32AM -0500, Rob Hutton wrote:
> It is partially fixed in session.inc, but not in session4.inc which I am
> using.
> 
> In session.inc, the correct variables are being used to build the url, but
> the note about not using the function is still there and I am not sure that
> the url needs to be encoded multiple times to reach the goal.
> 
> session4.inc is still using getenv('REQUEST_URI') to get the URL.  This does
> not work under IIS.
> 

I guess file a bug report.

RE: [Phplib-users] three tier auth made possible

[Rob H. <rob...@ws...>]

Gian,
  I disagree in your assertion that it is one or the other.  By providing a
function called do_auth that has a similar functionality to login_if, you
are providing and API call that allows you to control auth without putting
the auth logic into page.  Plus, start can still pick up the URL command for
those who want a quick and easy solution.
  Secondly, your example would be addressed in two parts I would guess.  A
auth_preauth function would be written that runs in start so that when you
browsed to site A or B, the other was queried through an XMLRPC interface to
see if you were already authenticated there, and if so, would give you the
same level of access.  If you were not, then (assuming blocking and not
default auth) if that failed it would show the login screen.
auth_handlelogin would take the results returned from the login form, check
it's local auth storage mechanism, check the other site through XMLRPC, and
if either one was successful, return the uid.  All of this with no logic in
page at all.
  As far as cross site registration, propagating information from one DB to
another is much better accomplished at the DB level.  Otherwise you end up
with problems like Site A was not Available at the time that site B disabled
an account.  Better yet, do centralized auth.  This is the Internet.  Or are
you saying that site B is the centralized auth source.

Thanks,
Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Giancarlo
> Sent: Thursday, October 31, 2002 6:13 PM
> To: phplib-users
> Subject: [Phplib-users] three tier auth made possible
>
>
> Now I go with my examples (and needs).
> Suppose I want Site A to release authentication based on being
> registered to
> Site B. All users registered at Site B are automatically
> authenticated for
> Site A too.
> The auth resides on Site B. Site B has an XMLRPC or SOAP or .NET xml
> interface that accepts  authentication info in the form of XML
> data, it has a
> services that, upon receiving XML credentials, replies with som XML data
> containing a kind of session token. Or, as an alternative, the XML
> credentials containing the login info are always passed back and
> forth with
> each request
> It can also receive some XML data to accomplish a registration.
>
> How could accomplish this using the existing phplib auth feature?
> I think by decoupling the testing of the user-provided input from
> the action
> itself.
> Site A gets the input via a form. Then SiteA calls the
> authentication service
> on SiteB and passes to it the values and a precisse request: authenticate
> this guy, or register this guy.
> SiteB replies with some token that Site A will keep in the session, and
> always will pass this over to  SiteB when requesting his features
> for the guy.
>
> So Site A propagates the session, but Site B does the authentication.
> Site B knows nothing of the input fields that are used in Site A
> pages. It
> only performs certain action upon receiving certain fields
> accompaigned with
> a certain request. Still the same authentication service of Site
> B should be
> used for visitors of his own site.
>
> Other examples, always in the same modulation:
>
> -All users that register at Site A will get automatically
> registersed also at
> Site B.
> -Users registered at Site A will then pull down some personalized content
> from their user profile at Site B
>
> How do you accomplish that if not by decoupling the registration
> process from
> the actual interaction with the client, included keeping the state
> propagation?
>
> So you see that  you can only accomplish this by keeping the
> authentication
> functions callable separately (not a cascade), unrelated to the input
> provided (abstract), not even related with any interaction with
> the client
> (no splash forms) etc. Auth becomes a service.
> Page.inc at this point (because it happens *before*calling the auth
> methods)can be a local interface that interacts with the local
> client, or a
> wire interface that handles thos XML/SOAP/.NET remota calls.
>
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

RE: [Phplib-users] auth url question

[Rob H. <rob...@ws...>]

  I don't agree with this approach because you are putting auth control
logic inside page and best practices are that the logic should reside in the
object itself.  My questions is whether login and register should be
separate objects.

  Two phased registration is where you register and then have to "activate"
the account via an email or some other process activates the account and
notifies you such as when a credit card has been approved.

  Approval registration is the same process as two phase, but instead of the
account being automaticly enabled by some means, the moderator must enable
the account.

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Thursday, October 31, 2002 5:17 PM
> To: rob...@ws...
> Cc: Phplib-Users
> Subject: MO: [Phplib-users] auth url question
>
>
>
> > > Single, two-phase, and approval based registration
> >
> > as you said, could easliy be added like this, in page inc
> >
>
> ### this mimics the auth->auth[uid]=='form' blocking login state
>  if($sess_login_in_progress)
>      {
>      if(!$auth->start('login')
>         {
>         page_showform();
>         }
>      else
>         {
>         unset ($sess_login_in_progress);
>         }
>      }
>
>
>
>
> >
> > ## this mimics the actual behavior
> >   if( ! $auth->start('authenticate') && (!$auth->start('login'))
> >     $auth->start('register')
>
> actually, the latter should be so:
>
>  ## this mimics the actual behavior: cascade
>    if((!$auth->start('authenticate'))
>      && (!$auth->start('login'))
>      && (!$auth->start('register')) {
>       page_showform();
>    }
>
> I can think more,
>
>  ## no cascade
>    if((!$auth->start('authenticate'))
>      {
>      if( ($whatever_trigger == 'login' && !$auth->start('login'))
>          ||($whatever_trigger == 'register')&&
> (!$auth->start('register'))
>          {
>          page_showform();
>          }
>      }
>
>
> What do you mean by 'two phase' and 'approval based' registration? What
> should be the steps?
>
>
> Gian
>
>
>
> > By having these three functionalities at hand, *separately, we
> can combine
> > them to get the  behaviors we want *out of, and apart from, the start
> > method*
> >
> > Gian
>

RE: [Phplib-users] auth url question

[Rob H. <rob...@ws...>]

OK, Joe and I had this disccussion too.  He wanted a function similar to
login_if, so I called it do_auth().  Same concept.  If you want to run auth
in the url mode, then start handles it.  If you want to run it in command
mode, that works too.

> -----Original Message-----
> From: Giancarlo [mailto:gia...@na...]
> Sent: Thursday, October 31, 2002 4:50 PM
> To: rob...@ws...
> Cc: Phplib-Users
> Subject: Re: [Phplib-users] auth url question
>
>
> Il 22:17, giovedì 31 ottobre 2002, Rob Hutton ha scritto:
> > Why do all three need to be run, the example that I sent
> handles all three,
> > 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 works...
>
> Then I prefer to call exactly what I want auth->start to do.
>
> So, eg (quick code), in page.inc:
>
>   if($whatever_we_want == "auth")
>    $auth->start('authenticate')
>   elsif ($whatever_we_want == "login")
>    $auth->start('login')
>   elsif ($whatever_we_want == "register")
>    $auth->start('register')
>
> That gives a lot more possibilities, because is done before and
> instead of
> calling the whole auth->start, and doesn't rely on any cascade logic, nor
> defers the trigger testing, to auth->start. I want to decide what auth
> function to call  case by case.
> With thsi structure it it more feasable to pilot the behaviour of
> auth, eg
>
> > Single, two-phase, and approval based registration
>
> as you said, could easliy be added like this, in page inc
>
> ### this mimics the auth->auth[uid]=='form' blocking login state
> if($sess_login_in_progress) {
>     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 combine
> them to get the  behaviors we want *out of, and apart from, the
> start method*
>
> 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ì 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 example.
> > > Add an input field to the register form, eg
> > > <input name=action value=register> and test it in auth_doregister.
> > > Same for validating the login, add
> > > <input name=actio value=login> in the loginform and test it in
> > > auth_validatelogin.
> > >
> > > Otherwise we cannot simply call auth->start and pretend it will do, by
> > > itself, any/everything needed. We'll need to call the three main start
> > > functions separately, as auth->start(authenticate),
> auth->start(login),
> > > auth->start(register). And this is definetely what I'd prefer.
> > >
> > > G
>

[Phplib-users] discussion, guidelines, paths

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

When there is no discussion what happens is either absolutely nothing, that 
means nothing moves nor get improved, or someone comes in like an hawk and 
commits his vision without sufficient consulting. This is obv?ously bad. 
Certainly someone will say 'who empowered this guy to impose his guidelines 
to the project' etc etc.

So then, when there is some discussion going on, as it has been for a while 
among the few who are giving a look at what is in the snapshot, regularly 
someone else comes out saying 'hey, we miss a guideline and e clear goal, we 
are going nowhere with these  endless disputes among ourselves'.

What can I say? There has been quite a good lot of clearification about the 
whole auth process, and why and how it was not properly working with default 
auth, and quite a few critic bugs have been found, and now this is all much 
more clear and simple than it was before, when the start method was a real 
mess. The code is there, is pretty readable, and once one understands the 
logic, it is really handable by anyone for his needs, which it was never 
before.

Whatever road phplib auth takes, one thing sure is that it will never revert 
to as it was before. So alleluja, let's be happy, we're better shape now. 
Give it a try, post your comments, I'll be back when something definite is 
been decided.

Gian

MO: [Phplib-users] three tier auth made possible

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

Il 00:12, venerd=EC 1 novembre 2002, Giancarlo ha scritto:

> How do you accomplish that if not by decoupling the registration proces=
s
                                                      ^^^^^^^^^^^^
                                                      authentication

> from the actual interaction with the client, included keeping the state
> propagation?
>
> So you see that  you can only accomplish this by keeping the authentica=
tion
> functions callable separately (not a cascade), unrelated to the input
> provided (abstract), not even related with any interaction with the cli=
ent
> (no splash forms) etc. Auth becomes a service.
> Page.inc at this point (because it happens *before*calling the auth
> methods)can be a local interface that interacts with the local client, =
or a
> wire interface that handles thos XML/SOAP/.NET remota calls.
>


Gian

[Phplib-users] three tier auth made possible

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

Now I go with my examples (and needs).
Suppose I want Site A to release authentication based on being registered to 
Site B. All users registered at Site B are automatically authenticated for 
Site A too.
The auth resides on Site B. Site B has an XMLRPC or SOAP or .NET xml 
interface that accepts  authentication info in the form of XML data, it has a 
services that, upon receiving XML credentials, replies with som XML data 
containing a kind of session token. Or, as an alternative, the XML 
credentials containing the login info are always passed back and forth with 
each request
It can also receive some XML data to accomplish a registration.

How could accomplish this using the existing phplib auth feature?
I think by decoupling the testing of the user-provided input from the action 
itself. 
Site A gets the input via a form. Then SiteA calls the authentication service 
on SiteB and passes to it the values and a precisse request: authenticate 
this guy, or register this guy.
SiteB replies with some token that Site A will keep in the session, and 
always will pass this over to  SiteB when requesting his features for the guy.

So Site A propagates the session, but Site B does the authentication.
Site B knows nothing of the input fields that are used in Site A pages. It 
only performs certain action upon receiving certain fields accompaigned with 
a certain request. Still the same authentication service of Site B should be 
used for visitors of his own site.

Other examples, always in the same modulation:

-All users that register at Site A will get automatically registersed also at 
Site B.
-Users registered at Site A will then pull down some personalized content 
from their user profile at Site B

How do you accomplish that if not by decoupling the registration process from 
the actual interaction with the client, included keeping the state 
propagation?

So you see that  you can only accomplish this by keeping the authentication 
functions callable separately (not a cascade), unrelated to the input 
provided (abstract), not even related with any interaction with the client 
(no splash forms) etc. Auth becomes a service. 
Page.inc at this point (because it happens *before*calling the auth 
methods)can be a local interface that interacts with the local client, or a 
wire interface that handles thos XML/SOAP/.NET remota calls.


 

MO: MO: [Phplib-users] auth url question

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

> I can think more,
>
>  ## no cascade
>    if((!$auth->start('authenticate'))
>      {
>      if( ($whatever_trigger == 'login' && !$auth->start('login'))
>
>          ||($whatever_trigger == 'register')&& (!$auth->start('register'))
>
>          {
>          page_showform();
>          }
>      }
>


The point is also that we should still be able of calling auth->start() the 
usual way, without any parameter, and be compatible with existing sites.

Gian

MO: [Phplib-users] auth url question

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

> > Single, two-phase, and approval based registration
>
> as you said, could easliy be added like this, in page inc
>

### this mimics the auth->auth[uid]=='form' blocking login state
 if($sess_login_in_progress) 
     {
     if(!$auth->start('login') 
        {
        page_showform();
        }
     else
        {
        unset ($sess_login_in_progress);
        }
     }




>
> ## this mimics the actual behavior
>   if( ! $auth->start('authenticate') && (!$auth->start('login'))
>     $auth->start('register')

actually, the latter should be so:

 ## this mimics the actual behavior: cascade
   if((!$auth->start('authenticate')) 
     && (!$auth->start('login'))
     && (!$auth->start('register')) {
      page_showform();
   }

I can think more, 

 ## no cascade 
   if((!$auth->start('authenticate'))
     { 
     if( ($whatever_trigger == 'login' && !$auth->start('login'))
         ||($whatever_trigger == 'register')&& (!$auth->start('register')) 
         {
         page_showform();
         }
     }         
     

What do you mean by 'two phase' and 'approval based' registration? What 
should be the steps?


Gian



> By having these three functionalities at hand, *separately, we can combine
> them to get the  behaviors we want *out of, and apart from, the start
> method*
>
> Gian

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

RE: [Phplib-users] auth url question

[Rob H. <rob...@ws...>]

> >
>
> I perfectly agree with this you said.
> The least we get HTTP_GET/POST_VARS hardcoded in the main start()
> function,
> the better it is for people to extend phplib to their needs.
> I myself like to have the possibility, from my proper version of page.inc
> (this means BEFORE invoking auth->start) to invoke separately,
> depending on
> my needs, any and each of the 3 main function start does:
> authenticate/login/register
>
But the URL is not hardcoded into anything!  It is a variable, and with the
duplicated functionality of login_if, then it can be called at start or
afterwards.  My concern is not how it is called, it is that start as it is
in the snapshot is unstructured.  It just calls stuff until something
happens.  And that is not good.

Re: [Phplib-users] auth url question

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

Il 15:53, gioved=EC 31 ottobre 2002, Matt Williams ha scritto:
> On Thursday 31 October 2002 14:23, Rob Hutton wrote:
> > The more I think about this, the less I agree, because I think that a=
uth
> > logic was/is flawed.  But attached is a version that I think will dro=
p
> > in.
>
> hi all
>
> I've missed most of this thread so forgive me if I've missed something =
or
> am heading off in the wrong direction.
>
> From what I gather a summary of this thread is about using mode=3Dreg o=
r
> something similar in the url to invoke registration, is this correct?
>
> From my point of the view this would be a waste of time. Each applicati=
on
>  that I use phplib on invariably has different requirements for
> registration. For me it is easier to keep registration to it's own page
> where I can control error checking on the form fields, add/remove field=
s as
> I wish without having to worry about anything in phplib that might get
>  broken/compromised in the process.
>

I perfectly agree with this you said.=20
The least we get HTTP_GET/POST_VARS hardcoded in the main start() functio=
n,=20
the better it is for people to extend phplib to their needs.
I myself like to have the possibility, from my proper version of page.inc=
=20
(this means BEFORE invoking auth->start) to invoke separately, depending =
on=20
my needs, any and each of the 3 main function start does:=20
authenticate/login/register

Gian

RE: [Phplib-users] auth url question

[Rob H. <rob...@ws...>]

Why do all three need to be run, the example that I sent handles all three,
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 works...

> -----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ì 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 example.
> Add an input field to the register form, eg
> <input name=action value=register> and test it in auth_doregister.
> Same for validating the login, add
> <input name=actio value=login> in the loginform and test it in
> auth_validatelogin.
>
> Otherwise we cannot simply call auth->start and pretend it will do, by
> itself, any/everything needed. We'll need to call the three main start
> functions separately, as auth->start(authenticate), auth->start(login),
> auth->start(register). And this is definetely what I'd prefer.
>
> G
>
>

Re: [Phplib-users] auth url question

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

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 aut=
h
> 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 somethin=
g
> 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 ca=
rds,
> or business presentation, or a lot of things.=20

auth_validatelogin and auth_doregister are in userland local.inc. A regis=
ter=20
form and a auth_doregister function is not even provided as an example.=20
Add an input field to the register form, eg=20
<input name=3Daction value=3Dregister> and test it in auth_doregister.
Same for validating the login, add=20
<input name=3Dactio value=3Dlogin> in the loginform and test it in=20
auth_validatelogin.

Otherwise we cannot simply call auth->start and pretend it will do, by=20
itself, any/everything needed. We'll need to call the three main start=20
functions separately, as auth->start(authenticate), auth->start(login),=20
auth->start(register). And this is definetely what I'd prefer.

G
=20

RE: [Phplib-users] Regex and Templates

[Rob H. <rob...@ws...>]

I figured as much, I just wanted to make sure I wasn't missing something.  I
added a [:punct:] tp the two pregs in template->finish() to exclude anything
with punctuation in it.

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Björn
> Schotte
> Sent: Thursday, October 31, 2002 2:43 PM
> To: Phplib-Users
> Subject: Re: [Phplib-users] Regex and Templates
>
>
> * Rob Hutton wrote:
> > The regex {6,32} expression to match 6 to 32 times gets eaten by the
> > templates when remove_unknowns is on.
>
> That's because it preg_replace()s all between { and }.
> Solution: set remove_unknowns to off, this should be
> sufficient (and, if there are any keywords that won't
> get replaced, manually set_var() them with "KEYWORD" => ""
> in order to remove it).
>
> Same for stylesheets you have in your template (of
> course one should define them via <link rel ...>
> so that browsers can cache them).
>
> HTH, Björn.
> --
> 35 Kundenportale mit mehreren tausend Nutzern erstellen.
> Bei geringen Kosten und einer großen Anzahl an Modulen
> (DMS, CMS, CRM, Community-Funktionen). Wie das geht?
> => http://testthesystem.com/     *      te...@th...
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>