Massimo - There is nonetheless the issue Bottiger points out that if "username" is passed in a form to this function, it will fail - there should be some reasonable behavior (as per the discussions here).
I think this is a separate issue from what extensions may want to do. I think we should address this also. Do you have any thoughts about how you would prefer (reading this thread)? Do you have some alternate ideas? Regards, Yarko On Fri, Aug 7, 2009 at 2:12 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > Hi Bottiger, > > When Auth was first developed was that if "username" is defined in a > custom "auth_user" table then it would be used. > > I do not think we should modify the auth_user table in order to allow > an extension (openid) to work. I would prefer to create a mechanism of > hooks by which the extension can create its own tables and forms as > required. Every login mechanism may have its own requirements. > > For example OpenID could have its own define_tables that makes openid > specific tables (including for example auth_user) then calls > Auth.define_tables for everything else. > > There should also be a hook to allow openid to build and process its > own login form (perhaps by overriding Auth.login). > > Make a proposal and I may accept a patch in this direction. > > On Aug 6, 9:08 pm, Bottiger <bottig...@gmail.com> wrote: > > At this point I think it would just be easier to let Massimo decide. > > > > Anyway, OpenID integration with Auth is coming along. It is usable but > > has some security concerns because people can change their OID in > > their profile. > > > > http://bitbucket.org/bottiger/web2py-openid-cas/overview/ > > > > On Aug 6, 7:05 pm, Yarko Tymciurak <yark...@gmail.com> wrote: > > > > > maybe a fifth option is to make the username a settable item, much like > > > auth_table_name is, > > > have a username_name item, and thus the tables can be defined this way? > > > > > The advantage is it would simplify the tools code (instead of adding > > > try/except), and > > > I think would serve the need you point out. What do you think? > > > > > Still just thinking out loud... > > > > > On Thu, Aug 6, 2009 at 9:00 PM, Yarko Tymciurak <yark...@gmail.com> > wrote: > > > > That's fine - then if you are building an OpenID application, you can > > > > either: > > > > manually have a separate field, or - have the OpenID solution modify > what > > > > the default auth fields are. > > > > > > This way, other apps still have choice. > > > > > > On Thu, Aug 6, 2009 at 8:54 PM, Bottiger <bottig...@gmail.com> > wrote: > > > > > >> > well, the problem then is that if you WANT to use email as > username, you > > > >> > have duplicate fields; > > > > > >> Actually as I am implementing OpenID, I am finding a need for a > > > >> separate field. In websites where you need to publicly display the > > > >> person's username, such as with comments etc... your users might not > > > >> like it if you displayed their email or First/Last name to the whole > > > >> Internet. > > > > > >> On Aug 6, 6:47 pm, Yarko Tymciurak <yark...@gmail.com> wrote: > > > >> > On Thu, Aug 6, 2009 at 8:42 PM, Bottiger <bottig...@gmail.com> > wrote: > > > > > >> > > Well you see, unlike the "username" column, the "email" column > is > > > >> > > actually defined. > > > > > >> > > So there are 3 possible solutions. > > > > > >> > > 1. Define a "username" column in the "auth_user" table by > default. > > > > > >> > well, the problem then is that if you WANT to use email as > username, you > > > >> > have duplicate fields; > > > >> > I don't like this solution; > > > > > >> > > 2. Change "username" to a column that is actually defined, such > as > > > >> > > "first_name" > > > > > >> > It would have to be unique, and this isn't reasonable constraint > for > > > >> > first_name or last_name (or even a combination of the two); > > > >> > I don't like this either; > > > > > >> > > 3. Remove the "username" check and usage completely. > > > > > >> > I think I like my action: try username if that is what is passed > in the > > > >> > dict, perhaps raise a ticket a single time, > > > >> > and fall back to 'email' if 'username' doesn't exist. > > > > > >> > What do others think? > > > > > >> > > On Aug 6, 6:38 pm, Yarko Tymciurak <yark...@gmail.com> wrote: > > > >> > > > I see - so you would want an exception to be raised? What do > you > > > >> > > propose? > > > > > >> > > > On Thu, Aug 6, 2009 at 8:26 PM, Bottiger <bottig...@gmail.com > > > > > >> wrote: > > > > > >> > > > > The function takes a dictionary where if the username key is > > > >> defined, > > > >> > > > > then it assumes that your database has a "username" column > which > > > >> is > > > >> > > > > incorrect behavior. > > > > > >> > > > > On Aug 6, 6:16 pm, Yarko Tymciurak <yark...@gmail.com> > wrote: > > > >> > > > > > On Thu, Aug 6, 2009 at 8:09 PM, Bottiger < > bottig...@gmail.com> > > > >> > > wrote: > > > > > >> > > > > > > I am using the latest version. > > > > > >> > > > > > By "latest version" do you mean revision 1062 from > Launchpad, or > > > >> do > > > >> > > you > > > >> > > > > > mean > > > > > >> > > > > > > I know there is a check, but the check is useless. If > you > > > >> specify a > > > >> > > > > > > username in the dictionary that comes with the argument, > then > > > >> it > > > >> > > will > > > >> > > > > > > automatically assume that your auth_users table has a > username > > > >> > > column, > > > >> > > > > > > which isn't the case. > > > > > >> > > > > > You you define the auth_users table, then you can define > this > > > >> > > additional > > > >> > > > > > field; > > > >> > > > > > if not, it uses the email field. > > > >> > > > > > This is how it is designed. > > > > > >> > > > > > Am I missing something? > > > > > >> > > > > > > On Aug 6, 5:58 pm, Yarko Tymciurak <yark...@gmail.com> > wrote: > > > >> > > > > > > > Which version of web2py are you looking at? > > > > > >> > > > > > > > First - in the most current version, I think you are > talking > > > >> > > about > > > >> > > > > line > > > >> > > > > > > 653, > > > >> > > > > > > > in > > > >> > > > > > > > get_or_create_user(); > > > > > >> > > > > > > > You will note at the beginning of that function: > > > > > >> > > > > > > > if 'username' in keys: > > > >> > > > > > > > username = 'username' > > > >> > > > > > > > elif 'email' in keys: > > > >> > > > > > > > username = 'email' > > > >> > > > > > > > else: > > > >> > > > > > > > raise SyntaxError, "user must have > username or > > > >> email" > > > > > >> > > > > > > > (there are 2 other places with lines like this, and > they do > > > >> > > similar > > > >> > > > > > > checks; > > > >> > > > > > > > so you can define a username in your auth, or by > default it > > > >> uses > > > >> > > > > email). > > > > > >> > > > > > > > You might want to get a look at: > > > > > >> > > > http://bazaar.launchpad.net/~mdipierro/web2py/devel/annotate/head%3A/<http://bazaar.launchpad.net/%7Emdipierro/web2py/devel/annotate/head%3A/> > <http://bazaar.launchpad.net/%7Emdipierro/web2py/devel/annotate/head%3A/> > > > >> < > http://bazaar.launchpad.net/%7Emdipierro/web2py/devel/annotate/head%3A/> > > > >> > > < > > > >> > http://bazaar.launchpad.net/%7Emdipierro/web2py/devel/annotate/head%3A/> > > > >> > > > > .< > > > > > >> > http://bazaar.launchpad.net/%7Emdipierro/web2py/devel/annotate/head%3A/ > > > >> > > > > .> > > > >> > > > > > > .. > > > > > >> > > > > > > > BEWARE: if you get the latest revision from > launchpad, > > > >> there is > > > >> > > a > > > >> > > > > bug in > > > >> > > > > > > > template.py - which I'm waiting for Massimo to apply > the > > > >> patch > > > >> > > for... > > > >> > > > > > > You > > > >> > > > > > > > can remove the ".read()" portion of line 120 yourself > in the > > > >> > > > > meantime, > > > >> > > > > > > that > > > >> > > > > > > > is in parse_template(): > > > > > >> > > > > > > > try: > > > >> > > > > > > > fp = open(t, 'rb').read() > > > >> > > > > > > > parent = fp.read() > > > >> > > > > > > > fp.close() > > > > > >> > > > > > > > should read: > > > > > >> > > > > > > > try: > > > >> > > > > > > > fp = open(t, 'rb') > > > >> > > > > > > > parent = fp.read() > > > >> > > > > > > > fp.close() > > > > > >> > > > > > > > - Yarko > > > > > >> > > > > > > > On Thu, Aug 6, 2009 at 7:29 PM, Bottiger < > > > >> bottig...@gmail.com> > > > >> > > > > wrote: > > > > > >> > > > > > > > > I am trying to incorporate OpenID into Auth. > > > > > >> > > > > > > > > In my attempt to implement a CAS style plugin into > auth, I > > > >> > > stumbled > > > >> > > > > > > > > upon a bizzare error. > > > > > >> > > > > > > > > On line 628 of gluon.tools, there is the following > line: > > > > > >> > > > > > > > > "users = self.db(table_user[username] == > > > >> > > keys[username]).select()" > > > > > >> > > > > > > > > username is defined to be "username" if you have a > > > >> username and > > > >> > > > > > > > > "email" if you have email specified. However, when I > > > >> looked at > > > >> > > the > > > >> > > > > > > > > auth_user table, there is no "username" column. > > > > > >> > > > > > > > > The closest thing to a username column is first_name > or > > > >> > > last_name, > > > >> > > > > but > > > >> > > > > > > > > obviously this isn't the same thing. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
