Add manage auth function to "welcome"

[Anthony]

Should we include something like this in the "welcome" app? It's a basic function for managing users, roles, and permissions. It uses smartgrid for users (with a link to db.auth_membership) and a standard grid for roles and permissions -- each loaded into a separate Bootstrap tab via LOAD(). (Note, currently there is no menu item linking to it, so that would have to be added.)

Anthony

[Massimo Di Pierro]

I am in favor adding the functionality. 

Can we implement it as an option for the user action instead and put the HTML into the existing user.html?

Also there should be a flag to enable this. People may already have an "admin" group and may not intend to use it in this way.

On May 30, 2013, at 12:21 PM, Anthony wrote:

Should we include something like this in the "welcome" app? It's a basic function for managing users, roles, and permissions. It uses smartgrid for users (with a link to db.auth_membership) and a standard grid for roles and permissions -- each loaded into a separate Bootstrap tab via LOAD(). (Note, currently there is no menu item linking to it, so that would have to be added.)

Anthony

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
<manage_auth.zip>

[Niphlod]

wasn't web2admin going to be considered for a "better" management ?

[Anthony]

On Thursday, May 30, 2013 2:30:03 PM UTC-4, Niphlod wrote:

wasn't web2admin going to be considered for a "better" management ?

That's still more general, like the current appadmin. The idea with this is to have a nice UI focused just on managing auth users, roles, and permissions.

Anthony 

[Niphlod]

uhm, sorry Anthony, I'm really tired ;-( . +1 on handling users, since it seems that is something users require a lot.

[Michele Comitini]

+1 

Did you also consider a plugin?

mic

2013/5/30 Niphlod <nip...@gmail.com>

--

[Chris Steel]

+1

On Thu, May 30, 2013 at 1:21 PM, Anthony <abas...@gmail.com> wrote:

Should we include something like this in the "welcome" app? It's a basic function for managing users, roles, and permissions. It uses smartgrid for users (with a link to db.auth_membership) and a standard grid for roles and permissions -- each loaded into a separate Bootstrap tab via LOAD(). (Note, currently there is no menu item linking to it, so that would have to be added.)

Anthony

--

-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Christopher Steel

www.chrissteel.com

[Anthony]

+1 

Did you also consider a plugin?

I'm sure a plugin with more sophisticated functionality could be developed, but the idea here is just to have some basic user/permission management built into the scaffolding app so you don't have to use appadmin (which exposes too much and isn't as user friendly).

Anthony

[Anthony]

OK, here's a new version. Now it is accessed via /default/user/manage. In order to avoid checking admin membership four times (main page plus once for each Ajax component), the Ajax requests are now made with digital signatures (somebody please check the logic to make sure there are no security holes). It also changes a few table and field labels to make them more user friendly (e.g., "Role" instead of "Group ID").

In Auth.__init__, there is now a new setting, auth.settings.manager_role, which defaults to "Access control manager" -- so this shouldn't interfere with apps that have an existing "admin" role.

I also changed the "divider" default in SQLFORM.smartgrid so there are now spaces before and after the ">" in the breadcrumbs -- I think this looks better.

The only thing missing is a menu item -- I was thinking of adding a link in the auth.navbar() menu. However, I didn't want to do an auth.has_membership lookup on every request to determine whether to include the link. Instead, it would probably be better to add a flag to the session at login and then just check the flag, but I'd like some feedback on that.

Note, I haven't done thorough testing and QA, but everything seems to be working.

Anthony

[Tim Richardson]

Apologies for this, but how do I apply the patch?
Here is what I tried.
I saved the attachment (unzipped) parent to my web2py git repository
I entered my web2py git repository in my own branch
I did
git am ../manage_access_control.patch

but the result was
Patch format detection failed.

[Anthony]

I generated the patch with Mercurial. Anyway, attached are the controller and view files. Then you only need to add one line to /gluon/tools.py, which you can see in the patch (there's also a line in /gluon/sqlhtml.py, though that's just cosmetic). You'll also need to create an Auth group called "Access control manager" (or you can call it something else, and then set auth.settings.manager_role to whatever you choose) and make the relevant users members of that group.

Anthony

[Tim Richardson]

Thanks. The patch applied with patch -p1 although I used your attached controller and view. I accepted the patch's update of tools.py and sqlhtml.py

I have created a group called Access control manager, a user and added the user to the group.
I tried to access default/user/manage

but I get authorisation errors so I guess I don't understand how to set up the group.

I don't understand how your code works.
To my naive eyes it seems that when I call default/user/manage  len(request.args) == 1 is True so it hits the return dict()

if len(request.args) == 1:
            auth.requires_membership(auth.settings.manager_group)(lambda: None)()
            return dict()

[Massimo Di Pierro]

This is in trunk with some changes.

Your code for manage has been moved to class Auth. The user.load is implicit in default.py.

<manage_access_control.zip>

[Massimo Di Pierro]

Please check it but, before we make this stable, I think we should consider make this code more general. Why should it be limited to edit the auth tables?

On May 30, 2013, at 11:38 PM, Anthony wrote:

<manage_access_control.zip>

[Anthony]

Your code for manage has been moved to class Auth. The user.load is implicit in default.py.

I had considered moving the code to the Auth class, and I don't necessarily object, but the reason I kept it in the application code was so it could serve more like a basic example that could easily be modified and customized. Once it's in Auth, you either take it or leave it. There are pros and cons to each approach. I might be more comfortable putting it in Auth if it were a little more polished and customizable (e.g., I think it would be ideal if when adding/editing a user, you could simply select a set of available roles from a multi-select rather than having to go to a separate "roles" table and add each role individually via a separate form). This was just intended to be a first effort at providing something basic and functional given that managing users and permissions is a common task. Anyway, I'm on the fence about it but just wanted to communicate the original rationale.

Please check it but, before we make this stable, I think we should consider make this code more general. Why should it be limited to edit the auth tables?

A more specific solution enables a UI and functionality that is more relevant to the particular context. In this case, there are tabs for Users, Roles, and Permissions. The Users tab uses smartgrid in order to allow assignment of roles, but the other two tabs do not. The Roles and Permissions tabs hide the record ID's, as they are not relevant for this purpose. Some of the table and field labels are changed to make things more user friendly in this context. These are context-specific tweaks that would not be available in a more general solution. I'm all for a better appadmin, such as web2admin, with different levels of permissions and more customizability, but I think there may still be a place for a more specific Auth management function (though ultimately the Auth-specific functionality could be built on top of the more general functionality).

A few other notes:

The reason I did:

auth.requires_membership(auth.settings.manager_group)(lambda: None)()

instead of:

if not self.has_membership(self.settings.manager_group_id):

was to take advantage of the specialized redirect code (with _next variables) done by auth.requires, depending on whether the failure is due to not being logged in or not being authorized.

In fact, I think we should tweak the auth.requires() code so call_or_redirect() takes the client_side argument (as most of the other redirects within Auth do). I'm also not sure all Ajax requests that fail authentication should be forced to get a simple 401 -- you may want a full client-side redirect to the login page in many cases.

Also, the new code does the auth.has_membership() check four times when the page is first loaded, and again for each operation. My code only did one check, when the page was first loaded -- all other requests were verified with a digital signature.

Finally, I think specifying the ID rather than the role name of the manager group may be dangerous. In the new code, the user() function has auth.settings.manager_group_id = 1. When looking at the code, not only is it unclear what that means, but it seems it would be easy to end up giving admin privileges to some random user if you don't initially set up an admin group. Specifying the role name instead does require an extra lookup initially, but I think it is safer and more clear.

Anthony

[Massimo Di Pierro]

I am not convinced default.py is a place for examples. If you want people to customize it, then perhaps it should be a plugin.

If we want to add an example in there I would do something small and harmless like

@auth.requires_membership('superman')

def manage():

      return dict(grid=SQLFORM.smartgrid(db.get(request.args(0)) or redirect(URL('index'))))

which is a blueprint to be used for everything.

[Anthony]

Well, maybe I shouldn't have used the word "example". The "welcome" app already includes code to make available all the end-user Auth functionality (including a specific controller action and associated view, as well as setup code in the models). I was just thinking of taking it a step further and adding some basic Auth admin functionality as well. Some people like to customize the end-user Auth functionality (custom login, registration, etc.), yet we still include the basics in "welcome" to serve as a starting point. Of course, I appreciate that we have to draw the line somewhere regarding what goes in "welcome", so maybe this doesn't belong. I'm OK with it either way -- just wanted to see what others thought.

I still might lean toward excluding it entirely rather than adding a new Auth method -- I suppose we could mark it as experimental, but at some point we'll be committed to keeping it as it is.

Anthony

[Niphlod]

Auth is quite big already.... Given that users are asking for this, I'd lean towards including code in welcome, or at least in appadmin.

[Massimo DiPierro]

How about we remove call() from welcome and add this instead:

@auth.requires_membership('superman')

def manage():

      return dict(grid=SQLFORM.smartgrid(db.get(request.args(0)) or redirect(URL('index'))))

At the same time we break appadmin in two parts (keeping one py file and one html file). One part requires admin, and one part requires "admin" membership?

Massimo

[Massimo DiPierro]

I moved the code from tools to appadmin.py and from user.html to appadmin.html.

Not convinced this is a good idea but better than too much pollution in default.py.

Moreover eventually we can add more "feature" to appadmin this way.

On May 31, 2013, at 12:25 PM, Anthony wrote:

[Tim Richardson]

I don't have any idea on how this works (from the user point of view). How to I access this manage function :) ?

[Massimo DiPierro]

Use appadmin to create a group, for example "test" and in your model say

   auth.settings.manager_group_role = "test"

Now anybody member of this group can access:

http://..../yourapp/appadmin/auth_manage # to manage permissions

http://..../yourapp/appadmin/manage # to manage the database

It is like an alternative nicer and safer appadmin interface which can be exposed.

On Jun 4, 2013, at 6:52 AM, Tim Richardson wrote:

I don't have any idea on how this works (from the user point of view). How to I access this manage function :) ?

[Tim Richardson]

Thanks.
tools.py in default_settings = dict(...
has manager_group_id = None  (line 881)
 so I was setting that in my model

I see now the logic in the appadmin controller

 

[Massimo DiPierro]

I am not so convinced this the right way and this kind of logic should be in appadmin. makes things more complicated to remember but often people ask for it.

[Anthony]

Note, appadmin checks for auth.settings.manager_group_role, but tools.py still has settings.manager_group_id (I prefer the former).

Anthony

[massimo....@gmail.com]

we ll go with role. will fix it asap. do you like the appadmin solution?


From my Android phone on T-Mobile. The first nationwide 4G network.

-------- Original message -------- Subject: Re: [web2py-dev] Add manage auth function to "welcome" From: Anthony To: web2py-d...@googlegroups.com CC:

[Anthony]

I haven't had a chance to look too closely, but putting it in appadmin isn't a bad idea -- kind of a compromise between the flexibility of sticking it in default.py and the commitment/restrictions of putting it in gluon. I do think it might make sense to have a way to separate permissions for auth_manage and the more general full db manage -- I think in many cases you want to give an admin user privileges to manage users but not necessarily to access every table in the database. That was somewhat the point of the original effort.

Anthony

[Tim Richardson]

Meanwhile, I can't get it to work.

I changed tools.py above, so no more tickets.
then I try:

http://127.0.0.1:8000/test_virtual_fields/appadmin/auth_manage/auth_user

and where I expect to see a grid I see nothing.
Looking at appadmin.html there should be a component (auth_manage.load) but I don't have it in my welcome app.
I'm not sure that I'm seeing the same repository that you guys are looking at.

[Massimo Di Pierro]

What's the error. If you not look for a .load view because it contains the logic:

return grid if request.extension=='load' else dict(grid=grid)

[Tim Richardson]

On Wednesday, 5 June 2013 00:28:16 UTC+10, Massimo Di Pierro wrote:

What's the error. If you not look for a .load view because it contains the logic:

return grid if request.extension=='load' else dict(grid=grid)

my bad, I thought I'd copied appadmin.html into my test app but hadn't.
Now it works. Very nicely too.


The code in HEAD fails because the setting auth.settings.manager_group_role is not defined when auth is created; instead, manager_group_id is created. This is one reason why I think that the git repository doesn't have the most recent code.


diff --git a/gluon/tools.py b/gluon/tools.py
index d9e03a4..e84f0b9 100644
--- a/gluon/tools.py
+++ b/gluon/tools.py
@@ -878,7 +878,7 @@ class Auth(object):
         alternate_requires_registration=False,
         create_user_groups="user_%(id)s",
         everybody_group_id=None,
-        manager_group_id=None,
+        manager_group_role=None,
         login_captcha=None,
         register_captcha=None,
         retrieve_username_captcha=None,
churchill:web2py tim$




 

[Tim Richardson]

OK, I see that below is done now.

-        manager_group_id=None,
+        manager_group_role=None,

[Massimo DiPierro]

Tim, thanks for all your work with book patches.

Massimo

[Anthony]

OK, I've made (what I think are) additional improvements in the attached patch. Now there is just one new appadmin function -- "manage". To get the special auth management page, you now just go to /appadmin/manage/auth instead of /appadmin/auth_manage. Also, permissions for managing auth are now separate from permissions for managing the whole database. In fact, it is now possible to define any number of separate roles that are allowed to access a specific list of db tables. This is done via a new Auth setting, auth.settings.manager_actions, which is a dictionary of dictionaries. Here's an example:

auth.settings.auth_manager_role = 'Access Control Manager'
auth.settings.manager_actions = dict(
    db=dict(role='Admin', heading='Manage Database', tables=db.tables),
    things=dict(role='Thing Manager', heading='Manage Things', db=other_db,
                tables=['things', 'stuff', 'more_stuff']),
    content=dict(role='Content Manager', tables=[content_db.articles, content_db.recipes, content_db.comments])
)

The keys of the auth.settings.manager_actions dict are URL args that go after /appadmin/manage -- so the above allows /appadmin/manage/db, /appadmin/manage/things, /appadmin/manage/content, and the special URL /appadmain/manage/auth (note, you cannot override the "auth" action).

Each item in auth.settings.manager_actions is a dict with "role", "heading", "db", and "tables" keys. The "heading" key is optional -- if there is no "heading", it will use 'Manage %s' % request.args(0).replace('_', ' ').title() instead. The "db" key is also optional -- it is only needed if you specify the "tables" as a list of table names and the tables are not in the auth.db -- in that case, you can specify the "db" either as a DAL object or as a variable name of a DAL object (which it will look up in globals()). You can also specify "tables" as a list of DAL Table objects, in which case the Table objects know their db, so you don't need the "db" key.

The view code has been simplified quite a bit as well.

Also, the patch includes some random fixes of misspellings of "unknown" as "unkown" in various files throughout gluon.

Anthony

[Tim Richardson]

On Thursday, 13 June 2013 07:34:53 UTC+10, Anthony wrote:

OK, I've made (what I think are) additional improvements in the attached patch. Now there is just one new appadmin function -- "manage".

These changes seem really good to me. I've sent a book patch to update the documentation. 

[Anthony]

Thanks. I haven't look at your book patch, but if it helps, here's a nicer write-up: https://groups.google.com/forum/#!msg/web2py/HdvSyZCJad4/5y1xQw3D2RgJ. Note, one difference in particular from my description in this thread -- you can in fact override the default /manage/auth action (though you will still get some of the specialized customizations of the labels, etc. in that case). I mentioned this change in the second post of the above linked announcement.

Anthony

[Anthony]

Note, one more update to the functionality that should be documented: https://groups.google.com/d/msg/web2py/HdvSyZCJad4/HLuyMJMRo1EJ.

Anthony

On Monday, June 24, 2013 10:13:18 AM UTC-4, Anthony wrote:

Thanks. I haven't look at your book patch, but if it helps, here's a nicer write-up: https://groups.google.com/forum/#!msg/web2py/HdvSyZCJad4/5y1xQw3D2RgJ. Note, one difference in particular from my description in this thread -- you can in fact override the default /manage/auth action (though you will still get some of the specialized customizations of the labels, etc. in that case). I mentioned this change in the second post of the above linked announcement.

Anthony

On Monday, June 24, 2013 10:01:21 AM UTC-4, Tim Richardson wrote:

[Tim Richardson]

Anthony,

I was testing this prior to updating the documentation, and I ran into a problem.

The screen to edit the tables has a component which displays "loading..." without succeeding.

This is with trunk. I copied the latest controller and view from Welcome. 

Code in my model:

auth.settings.manager_actions = dict(db_admin=dict(role='admin',heading='Manage Database',tables = db.tables))

and the menu:

(T('User Management v2'),False,URL('appadmin','manage',args=['db_admin']))

[Anthony]

Is this with an existing app, where you just copied the appadmin.py controller and appadmin.html view from trunk welcome app? Did you also copy the latest web2py.js from welcome? That is needed for components to work properly with trunk.

Anthony

[Tim Richardson]

Ah,

Thanks. That was the problem.

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---

You received this message because you are subscribed to a topic in the Google Groups "web2py-developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py-developers/e0BaYjlHsO0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py-develop...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Tim Richardson, Director Mobile: +61 423 091 732 Office: +61 3 8678 1850 GrowthPath Pty Ltd ABN 76 133 733 963

[Niphlod]

asking one more time again.... we should put the advice on top of web2py-users to get prepared to all users asking about this :P

[Tim Richardson]

In this case it is necessary even in an app not explicitly using components, because the new privileged-user database maintenance does use them.

Perhaps every app needs to update web2py.js 

[Anthony]

On Wednesday, July 24, 2013 11:00:13 PM UTC-4, Tim Richardson wrote:

In this case it is necessary even in an app not explicitly using components, because the new privileged-user database maintenance does use them.

Perhaps every app needs to update web2py.js

Yes, in general, web2py.js should always be updated whenever upgrading the framework -- it's part of the framework. 

[Tim Richardson]

Anthony, there's an open pull request with the new documentation for the user admin feature. You did an awesome job on this functionality. It's great the way you generalised it. 

[Anthony]

Thank you.