It is true that limiting the number of Users and setting security
levels are matters of site policy, but they are such common issues
that I thought it worthwhile to build them in. Both features are
defaulted in the constructors so that they can simply be ignored if
not wanted.

Jim Dukarm
DELTA-X RESEARCH

> On 21 November 2002, Jim Dukarm said:
>> My User and UserManager classes (attached) are pretty lightweight and
>> might be the right sort of thing for Quixote. I just revised them,
>> using some tricks from Quixote's Session and SessionManager to make
>> them more friendly to subclassing.
>>
>> The UserManager, like the SessionManager, can be initialized with any
>> kind of mapping for storage - persistent or not - of User instances.

> Ooh, I like it when someone uses my good ideas in ways that had not
> occurred to me.  I quite like SessionManager's persistence non-model
> (ie., DIY and here's how) -- no reason it shouldn't work for users.
> Nice!

>> The maximum allowable number of Users can also be specified.

> Why?  That sounds like a local policy decision (not just the maximum
> number, but the very idea of limiting the number of users in the
> system).

>> As written, the User keeps its password in encrypted form. By
>> subclassing User and overriding the _encrypt method, you can keep the
>> password as open text, if desired.

> Hmmm, that might be the right way to do it.  I'd still like Quixote to
> provide a plaintext password version of User for sites that value the
> ability to mail existing passwords back to users, but the more secure
> version should be the default.

>> The User has an integer security level, which is useful for
>> discriminating between, say, read-only users, data-entry users, and
>> admin users.

> That's definitely policy.  I lean towards a model where every user has a
> set of orthogonal privileges -- but again, that's site policy and does
> not really belong in Quixote.

>         Greg