> A basic idea is this:
>
> Each user has a user id (string) and a password (string-hashed). The
> system also stores a UID (string) and a system UID (string). It also
> generates a temporary ID called, say, temporary (string). Authentication
> is like this:
>
> LOGON
[snip]
> Use symmetric DESede key to decrypt user's profile information.
While I agree with what you're saying, I'd just like to point out what I
believe to be a flaw in the kind of profile management you seem to be
proposing (whether by intent or not - it doesn't matter, I think this issue
should be brought up in any case).
Am I correct in thinking that the idea is that upon login, the profile
(applications settings, etc - something like the user specific registry info
on Windows?) gets loaded, possible changed by running programs, and then
stored again on disk when one logs out?
The problem with this is that it interferes with multiple logins. This is a
problem one sees in a Windows environment with roaming profiles. When a
person logs onto a NT box, the client will get update it's local profile
with that on the server. When you log out, the server profile is
synchronized with the client-side one. This obviously creates huge problems
with regards to being logged in multiple times from different locations (and
then there's the problem of re-transfering a 500 mail file on the net
everytime it changes... but that's besides the point).
So while the idea of sessions is obviously a requirement (and a great thing
if you make them persistent across logins), I believe any "profile" data
should be accessed directly on disk (or wherever the "authorative" copy resides).
--
/ Peter Schuller, InfiDyne Technologies HB
PGP userID: 0x5584BD98 or 'Peter Schuller <[EMAIL PROTECTED]>'
Key retrival: Send an E-Mail to [EMAIL PROTECTED]
E-Mail: [EMAIL PROTECTED] Web: http://scode.infidyne.com
_______________________________________________
General maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/general
