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
>