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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

  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
>