TG_User should really be TG_SP_Basic Each local (i.e. having data on the server => not LDAP and alike) Security Provider (SP) would have it's own table.
Justin Johnson wrote: > > > 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/ >> >> > >
signature.asc
Description: OpenPGP digital signature
