laziness, impatience, and hubris | |
PerlMonks |
Re: Where to get this kindof advice.by nothingmuch (Priest) |
on Oct 26, 2005 at 08:54 UTC ( [id://502980]=note: print w/replies, xml ) | Need Help?? |
I think the wisest choice is to make a rich authorization system.
The most adequate design I can think up is one where each operation triggers a hook that makes a query into the system to find the needed attributes for that op. The other part is the object representing the user's session - it also has attributes. Since you speak of this virtual filesystem that owns all the data in the project attributes on users and attributes on parts of the filesystem can be embedded in the filesystem too. This may sound tempting, but I'd be weary of overabstracting. Then you should design it to make it easy to do two things:
It's a sad fact, but all layers of abstraction can sometimes have an unforeseen limiting factor. If your legal department can handle the waiver safely i think making SSL optional a good idea, since it will give your clients more choices on how they want to work with you. I doubt this will come up in practice that often. Lastly, it might be wise to use a certificate system to ensure that the authz process verifies that the waiver is cryptographically signed by the client (where a the cryptographic signature can be made on behalf of the client when they physically signed the waiver), and that the signature is signed by an authority (or organizations operators). That way at least the protocol is very clear and well defined.
-nuffin zz zZ Z Z #!perl
In Section
Seekers of Perl Wisdom
|
|