Absolutely agree with having something usable out the box. But ideally
the User model would be a base class that could be expanded on rather
than second guessing some fields that everyone, or no-one, will want.
Especially if those fields aren't actually used in the rest of security
model code.
It would be a shame to produce a feature set of the base distribution
that needs changes to the source code to use it in production after
those first 'wow' moments.
The only extra code for demo's/quickstart model would be:
class DemoUser(TG_User):
email=UnicodeCol()
displayName=UnicodeCol()
given that TG_User contained only id+passwd and inherited from
InheritableSQLObject rather than SQLObject.
The goal of the Identity framework is to provide a usable system out
of the box. This includes the fields most applications are likely to
use. I recognise this isn't the ideal for everyone, but it allows
developers to be productive quickly.
At some point I hope to put together a nice admin interface for
identity, which will work with the default model. This means
developers can get going without any real code.
On 7 Jan, 2006, at 5:18 pm, Olivier Favre-Simon wrote:
Entirely agreed.
Basic auth must be _basic_ => id+passwd
Not just display name but all personal data has nothing to do with
security and is fully application-specific.
This holds for the email field.
Identity is working good but may be some of the most security-aware
readers of this ML should help here: Even a good implementation doesn't
shield against all pitfalls when it comes to security.
Justin Johnson wrote:
While browsing through the source for up and coming 0.9, I've noticed
the following TG_User comment:
'''
Reasonably basic User definition. Probably would want additional
attributes.
'''
Does this mean that the intention is to further add attributes? As a
suggestion - that might not be desirable.
For example, I'm working on a system where I already have a User class
that contains id, password, email and creation date. Basic stuff.
I'm representing further user information such as gender, date of
birth, location etc through a separate table. My User model really
just acts as the gate keeper data to the system and is minimal.
Now, TG_User also has 'displayName' which is a 255 length description
field! On my set up I'd put that in my separate table. Some apps
wouldn't have any use for it at all.
This is application dependent and my feeling is that the identity
system should just provide the absolute minimum to incorporate security.
Would it be possible to have this so that you can specify your own
User model?
Otherwise, great job and I look forward to using it! :)
--
Jeff Watkins
http://newburyportion.com/
