1) good point. We have the following functions but they are not documented:
def get_or_create_user(self, keys, update_fields=['email']): def login_bare(self, username, password) 2) you can use auth.define_tables(username=True) so that email is not used for login. The problem is that you still need to communicate with users and this is what the email field is for. In principle you can hide the email field if you do not need to comunicate with users. Please open a ticket for improvement and list APIs you would want to have. I will probably add them. On Thursday, 29 November 2012 09:09:49 UTC-6, Magnitus wrote: > > Sincere apologies for poking holes at this beautiful framework, but while > I'm in here, I have another issue I encountered while using the framework. > > I'm only expressing hurdles I've encountered while using the framework in > the hope that it can give the devs some insights on how the framework can > be improved. > > Out of the box, the user account mechanism is limited in at least 2 ways > that I noticed. > > 1) Reliance on Form > > The functions that Auth provide to interact with user accounts return > Forms which I consider to be very high level functionality. > > It would be nice if it provided slightly lower level functionalities like > Register_user(<Pass Info as Parameters>), Change_password(<Pass Info as > Parameters>), Login(<Pass Info as Parameters>), Logout() in order to allow > programmers to more easily combine the RBAC access control with their own > account management facilities (as long as they pass the right parameters to > the API, web2py shouldn't care). > > web2py could even keep it's high-level form reliant functionality, but > also provide the lower level API. > > 2) Reliance on the Email Field > > I know that this is what users will want 99% of the time when making your > standard web site, but there are non-standard scenarios. > > For example, at some point, I created a tool for a small group of people > where user accounts are updated when the admin copy-paste a page from > another web site into the parser (which returns a list containing all the > new usernames/passwords as well as a list of deleted users). > > Another example: I'm wroting a tool that provides a service on your LAN, > via a local web server. The tool needs to create exactly one account (which > is first created via a web GUI for user-friendliness) and given the nature > of the tool, email information is superfluous. > > In both these scenarios, I have to insert bogus emails to make the out of > the box authentication work. > > It would be nice if the email field was optional when when username is > used. > --
