The user function remains as-is - No modifications done.
def user():
"""
exposes:
http://..../[app]/default/user/login
http://..../[app]/default/user/logout
http://..../[app]/default/user/register
http://..../[app]/default/user/profile
http://..../[app]/default/user/retrieve_password
http://..../[app]/default/user/change_password
http://..../[app]/default/user/bulk_register
use @auth.requires_login()
@auth.requires_membership('group name')
@auth.requires_permission('read','table name',record_id)
to decorate functions that need access control
also notice there is http://..../[app]/appadmin/manage/auth to allow
administrator to manage users
"""
return dict(form=auth())
I am using the specified functions to expose methods as below -
# ---- User functions ---
def login(): return dict(form=auth.login())
def register(): return dict(form=auth.register())
def retrieve_password(): return dict(form=auth.reset_password())
def logout(): return dict(form=auth.logout())
def profile(): return dict(form=auth.profile())
and the corresponding files reside in \views\ *not in* \views\default - I
am not sure if the application is even picking up these files.
Note - I have extended the Auth (auth_user) table and added workspace and
other fields - This will be specified everytime I add a new user. I would
filter out the results as you mentioned but only after all the login stuff
works properly.
auth.settings.extra_fields['auth_user'] = [
Field ('workspace', length=128),
Sincerely,
Rahul
On Tuesday, October 23, 2018 at 7:49:48 PM UTC+5:30, Jim S wrote:
>
> Did you modify the user() function in default.py? Or, are you using your
> own custom login functions?
>
> -Jim
>
> On Tuesday, October 23, 2018 at 7:59:21 AM UTC-5, Rahul wrote:
>>
>> Hi Jim, All,
>> Okay I tried this - And I also decorated index() function in
>> controller like below as I want to redirect the user to login page rather
>> than directly jumping to index.html
>>
>> # ---- example index page ----
>> @auth.requires_login()
>> def index():
>> response.flash= T("Hello World")
>> return dict(message=T('Welcome to web2py!'))
>>
>> However, now when I put the credentials username and password, it doesnt
>> log me in - I generates the below URL like below and appends it to url box.
>> What might I be missing because it was logging me in fine sometime ago but
>> now it doesnt allow. Note I did cleanup a lot of HTML code from my login
>> page. There sure is something going on here that I am not catching -
>>
>>
>>
>> http://
>> 127.0.0.1:8000/scaffolding_app/default/user/login?username=rahul&password=integer10&_next=%2Fscaffolding_ace_admin%2Fdefault%2Findex&_formkey=0c0c022a-377d-47dd-bd72-a13e8ee6f387&_formname=login
>>
>>
>>
>>
>>
>> Sincerely, Rahul D.
>>
>>
>> On Friday, October 19, 2018 at 12:24:19 PM UTC+5:30, Rahul wrote:
>>>
>>> Hi Jim,
>>> That makes sense. I will check it out on which option to go.
>>> Thanks! for all the guidance.
>>>
>>> Thank you,
>>>
>>> *Rahul Dhakate*
>>>
>>> On Wednesday, October 17, 2018 at 7:57:32 PM UTC+5:30, Jim S wrote:
>>>>
>>>> Rahul
>>>>
>>>> First, what I was referring to was common_filters, not common fields.
>>>> Here is the scenario as I see it.
>>>>
>>>> In you auth_user table you have a workspace field. Then in other
>>>> tables that are workspace-specific you also have a workspace field to show
>>>> which workspace they relate to
>>>>
>>>> Here is how I think I would handle it, assuming I am understanding your
>>>> need. And, assuming that the workspace identifier is stored on the user
>>>> record. You wouldn't gather it on the login page.
>>>>
>>>> In db.py I'd have code that would check to see if the user is logged
>>>> in. If so, then set the common filters for the workspace-specific tables
>>>>
>>>> if auth.is_logged_in:
>>>>> db.related_table_1._common_filter = lambda query:
>>>>> db.related_table_1.workspace = auth.user.workspace
>>>>> db.related_table_2._common_filter = lambda query:
>>>>> db.related_table_2.workspace = auth.user.workspace
>>>>> db.related_table_3._common_filter = lambda query:
>>>>> db.related_table_3.workspace = auth.user.workspace
>>>>> db.related_table_4._common_filter = lambda query:
>>>>> db.related_table_4.workspace = auth.user.workspace
>>>>> ...etc...
>>>>
>>>>
>>>> Make sense?
>>>>
>>>> Anyone else out there that's done this and can show a better way?
>>>>
>>>> -Jim
>>>>
>>>>
>>>> NOTE - you might also skip the common filters if you're logging in as
>>>> an admin. Then you might want to see data for all workspaces
>>>>
>>>> NOTE 2 - If you really want people to specify their workspace when they
>>>> login (meaning they have access to all of them but they choose which one
>>>> on
>>>> login) then you'd have to override the default login code to gather that
>>>> extra variable and store it in your session somewhere. Then use that
>>>> instead of auth.user.workspace when building your filters.
>>>>
>>>>
>>>>
>>>> On Wed, Oct 17, 2018 at 2:06 AM Rahul <[email protected]> wrote:
>>>>
>>>>> Hi Jim,
>>>>> I am afraid no I didn't check that section but I just
>>>>> finished reading it. Thanks! for directing me to it. Looks like a new
>>>>> addition to DAL (might be a couple of versions back) & looks promising.
>>>>> So
>>>>> now, we can specify something like request_tenant using db._common_fields
>>>>>
>>>>> field parameter.
>>>>>
>>>>> I would need it for all tables so is there a specific syntax like
>>>>> below that I am required to specify in each table I create ?
>>>>>
>>>>> db._common_fields.append(Field('request_tenant',
>>>>> default=request.env.http_host,
>>>>> writable=False))
>>>>>
>>>>>
>>>>> Also, can we set the default value to a field value that we can query
>>>>> or pass as a session variable like session.workspace == 'some workspace
>>>>> name' while the user logs in ?
>>>>>
>>>>> default=session.workspace,
>>>>>
>>>>>
>>>>> If yes - what do I need to modify to add this additional field in Auth
>>>>> so it will be an input field for the user to key in the workspace name.
>>>>> Then I can store this workspace in session variable and use it. The
>>>>> reason
>>>>> is I want a group of users (accessing the same app and database from
>>>>> different locations) belonging to same workspace. This is how they are
>>>>> grouped. please see the screenshot posted from my actual application
>>>>> login.
>>>>> In it I use workspace name as well to validate but after reading the book
>>>>> seems like we would not require workspace for validation if we can have
>>>>> the
>>>>> user provide the field for redirection and for us to grab the session
>>>>> variable.
>>>>>
>>>>> Or is this not needed at all after we use common fields ?
>>>>>
>>>>> I hope I am clear and make sense :-)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rahul
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, October 16, 2018 at 7:49:49 PM UTC+5:30, Jim S wrote:
>>>>>>
>>>>>> Have you looked at common filters?
>>>>>>
>>>>>>
>>>>>> http://web2py.com/books/default/chapter/29/06/the-database-abstraction-layer?search=common+filter#Common-filters
>>>>>>
>>>>>> -Jim
>>>>>>
>>>>>> On Tuesday, October 16, 2018 at 7:35:04 AM UTC-5, Rahul wrote:
>>>>>>>
>>>>>>> Hey Everyone,
>>>>>>> Greetings! I have a question. I went through Auth
>>>>>>> documentation and understood that we can add extra fields to the Auth
>>>>>>> tables. However, I still want to be a little more clear to achieve
>>>>>>> below -
>>>>>>> I am currently using three fields for a multi-tenant system like
>>>>>>> workspace,
>>>>>>> username and password. Here workspace depicts where the user belongs to
>>>>>>> (see explanation in Q1 below) I am currently using my own code to
>>>>>>> manage
>>>>>>> this stuff manually (almost everything that auth does), now though I
>>>>>>> want
>>>>>>> to give Auth a try and tailor it to fit my needs. I dont want to
>>>>>>> maintain
>>>>>>> that amount of code and use the existing API. Can I get help on
>>>>>>> achieving
>>>>>>> that in the simplest way. If it works, I would switch to using Auth
>>>>>>>
>>>>>>> * Q1]* How can we use Auth to add one more extra field for
>>>>>>> authentication when I want a system to validate login based on three
>>>>>>> parameters like - Validation needs to be done based on all three
>>>>>>> parameters
>>>>>>> specified. For each application I can use 'n' number of unique
>>>>>>> workspaces
>>>>>>> and 'n' number of users would belong to these workspaces. How to do
>>>>>>> this ?
>>>>>>>
>>>>>>> 1. *workspace *- An alpha numeric field that would store a
>>>>>>> unique name denoting users belonging to a particular set (For
>>>>>>> example
>>>>>>> users working in a specific location like los-angeles or
>>>>>>> washington) or
>>>>>>> an office location like michigan, nevada or Zones like north, south
>>>>>>> ..
>>>>>>> sort-of etc. )
>>>>>>> 2. *username *- Its available already
>>>>>>> 3. *password *- Its available already
>>>>>>>
>>>>>>>
>>>>>>> *Q2]* Which all tables need to be modified ?
>>>>>>>
>>>>>>> *Q3] *Any changes in any other code in any files ?
>>>>>>>
>>>>>>> I know I can clone my app multiple times and support multi-tenancy
>>>>>>> however, if this can be achieved with Auth - that would be great.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> *Rahul *
>>>>>>>
>>>>>> --
>>>>> Resources:
>>>>> - http://web2py.com
>>>>> - http://web2py.com/book (Documentation)
>>>>> - http://github.com/web2py/web2py (Source code)
>>>>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>>>>> ---
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "web2py-users" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/web2py/6SscBvMorU0/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> [email protected].
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
