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 -~----------~----~----~----~------~----~------~--~---
