There's always a way... Auth can help the developer, that means: - no automatic updating by auth - auth can provide helpers to developer to help with some stuff or as testers (eg doctest can ask auth to check your data model)
On Sun, Jul 12, 2009 at 8:04 PM, Yarko Tymciurak<[email protected]> wrote: > On Sun, Jul 12, 2009 at 1:00 PM, Yarko Tymciurak <[email protected]> wrote: >> >> On Sun, Jul 12, 2009 at 12:53 PM, Jonathan Lundell <[email protected]> >> wrote: >>> >>> On Jul 12, 2009, at 10:00 AM, mdipierro wrote: >>> >>> > >>> > correct on both accounts. I will get this fixed in the code and the >>> > manual. Thanks. >>> >>> I'm not familiar enough with the DAL to know if this makes complete >>> sense, but might it be reasonable for Auth.define_tables to add >>> required fields and validations to the user table (and perhaps other >>> tables) if they're missing? >>> >>> That would have at least three benefits: a developer wouldn't have as >>> much to do when extending the table(s); it would ensure that the >>> security-related validations are in place; and it would effectively >>> migrate existing tables the next time web2py is updated and run. >>> >>> define_tables might end up looking like this: >>> >>> if (no user table) >>> define a user table >> >> I think this is the way it works already... either define your own table, >> or let Auth... >> >>> >>> if (no required-field x) >>> define required-field x >>> if (no required-field y) >>> define required-field y >>> if (field y doesn't have validation v) >>> add validation v to field y >>> etc... >> >> From a development perspective, this might be dangerous - side effects. >> If your table has minimum requirements for Auth, good; if not, Auth >> complains, and lets the developer handle the change. > > ...that is to say criss-crossing responsibilities like this is not a good > thing: > either you (developer) claim responsibility for the table definition, or the > Auth class does... > for you to extend some things (define table), and still let Auth override > your work is... messy. -- It's dual responsibility; the same argument > against it is the one that eternally goes against global data - when no one > piece is clearly responsible, all sorts of problems come out.. > >> >> >> >>> >>> >>> Perhaps there's an easier way, but you get the idea. >>> >>> > >>> > Massimo >>> > >>> > On Jul 12, 11:44 am, Jonathan Lundell <[email protected]> wrote: >>> >> In Auth.define_tables we define the user table thus: >>> >> >>> >> if not self.settings.table_user: >>> >> passfield = self.settings.password_field >>> >> self.settings.table_user = db.define_table( >>> >> self.settings.table_user_name, >>> >> db.Field('first_name', length=128, default=''), >>> >> db.Field('last_name', length=128, default=''), >>> >> # db.Field('username', length=128, default=''), >>> >> db.Field('email', length=128, default=''), >>> >> db.Field(passfield, 'password', readable=False, >>> >> label='Password'), >>> >> db.Field('registration_key', length=128, >>> >> writable=False, readable=False, >>> >> default=''), >>> >> >>> >> migrate=self.__get_migrate(self.settings.table_user_name, migrate)) >>> >> table = self.settings.table_user >>> >> table.first_name.requires = >>> >> IS_NOT_EMPTY(error_message=self.messages.is_empty) >>> >> table.last_name.requires = >>> >> IS_NOT_EMPTY(error_message=self.messages.is_empty) >>> >> table[passfield].requires = [CRYPT()] >>> >> table.email.requires = >>> >> [IS_EMAIL(error_message=self.messages.invalid_email), >>> >> IS_NOT_IN_DB(db, '%s.email' >>> >> % >>> >> self.settings.table_user._tablename)] >>> >> table.registration_key.default = '' >>> >> >>> >> In Auth.register, we have the following auto-login sequence; there's >>> >> similar logic in Auth.login, but it's clearer here: >>> >> >>> >> else: >>> >> user[form.vars.id] = dict(registration_key='') >>> >> session.flash = >>> >> self.messages.registration_successful >>> >> table_user = self.settings.table_user >>> >> if 'username' in table_user.fields: >>> >> username = 'username' >>> >> else: >>> >> username = 'email' >>> >> users = self.db(table_user[username] == >>> >> form.vars[username])\ >>> >> .select() >>> >> user = users[0] >>> >> user = Storage(table_user._filter_fields(user, >>> >> id=True)) >>> >> session.auth = Storage(user=user, >>> >> last_visit=request.now, >>> >> >>> >> expiration=self.settings.expiration) >>> >> self.user = user >>> >> session.flash = self.messages.logged_in >>> >> >>> >> Finally, the manual "Customizing auth_user" says, 'If you add a field >>> >> called "username", it will be used in place of the "email" for >>> >> login.' >>> >> We see the username/email logic in Auth.register. >>> >> >>> >> The problem is that the username field needs (like email) to be >>> >> IS_NOT_EMPTY and IS_NOT_IN_DB, or the obvious bad thing can happen. >>> >> >>> >> Is it enough to mention the need for the validations (maybe a >>> >> complete >>> >> sample line) in the manual? >>> >> >>> >> Finally, shouldn't both email and username require unique=True? >>> > > >>> >>> >>> >>> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
