Re: [phplib] Remote session/authentication From: Sam C. Nicholson !! (scion <email protected>)
Date: 07/31/01

From: "Guillaume Desclaux" <gdesclaux <email protected>>
Date: Tue, 31 Jul 2001 19:40:32 +0200

>Yes of course : I've not properly explain what I've mean : I mean :
>shared a file via Samba or NFS is not probably the most "universal"
>method to share this kind of information between web server...
>
>> If NFS isn't allowed to all of your client servers, then you can't use NFS.
>
>yes indeed ;-)

It's a continual source of amazement to me the folks that just can't
cope with this. It's the same mentality that want's to use a *reliable*
transport because it's "better." I always reply by asking how the
transport will reliably operate across that fibre cut?

>
>> No matter which data sharing method you use, you must allow remote access to
>> the data. If this is a problem, then you must evaluate each method to find
>> the method which meets the most requirements, and then patch/politic around
>> the rest.
>>
>When you wrote "any client" : you mean "any web server using the remote
>authentication class of the phplib 8.x" ?

No, I was speaking generically. I meant *any* client of whichever distributed
auth scheme that one happens to decide upon.

And then:
>
>> In all of these cases one must plan for network partitions. They will happen;
>> even on a LAN, even on a shared resource system (though for very short times.)
>>
>> I generally deal with a partition from the auth source by caching a local copy
>> at each access time. Then if a user returns, yet I cannot see the master data
>> source, I will allow read-only access. This splits the middle between absolute
>> auth and convenience.
>
>As I said : share data via NFS/Samba with a networks partitions is not
>,in my opinion, the best solution to share data with remote server...
>there is a lot of pb with firewall, and so on... I'm thinking about an
>XML stream or some WDDX web site syndication to do that...

Yes, indeed.

And perhaps what I didn't say as well as I should, was that it doesn't matter
*what* transport you use to move the auth data around with, you have the
problem of network partitions. And that's all I really wanted to say.

To be useful, the scheme needs to decide what it wan't to do when it can't
see the data source. Does it maintain a local cache? Does it fallback to
some default access?

What I found really useful about the move to php4 sessions was that by
simply sharing files (read-only, even), I could allow new apps to use the
same auth structure and data. Having only one writer was not an issue,
as I force auth to go via https, so then all that is shared in the open
is read-only data. And that was allowable, so I was done!

My auth struct looked like /var/userdb/sessions/$sessionid/$userid
My cached auth struct was /cache/userdb/sessions/$sessionid/$userid/$timestamp
Each client writes a copy of the auth info in its local /cache or
updates (via rename()) the timestamp after a quick check of the server
info along the /var/userdb path.

And by cacheing this copy just after auth, I could continue to allow access
until $timestamp+TIMEOUT seconds.

-sam 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>