Feedback on role enforcement patch and a pending commit

[Trevor McKay]

Hello all,

  I played with the patch yesterday, and I think it's close to something
we can distribute in general from trunk.  Here are few items, in no
particular order.  Please share your thoughts.

1) I prototyped a redirect solution, about to commit to the branch.  It
specifies a fallback page per group in the xml file.  When a user
touches an unauthorized widget, the fallback page is read based on the
group and a redirect is sent.  Not much code and it seems to work well
-- it solves the "login" issue for groups not authorized to see
index.html, which was the biggest issue.  Let me know what you think.

(this can be improved slightly if the redirect from a login form looks
up the user's group first, before going straight to index.html, so we
don't get a double redirect, but that is minor)

2) I wonder about the naming convention used in the xml file.  There is
already an internal naming convention that is used within a page.  It
names widgets based on their placement in the hierarchy.  It's used
internally in a few places to navigate, and it's used in generating URLs
(page_widgets_by_path[] I think is an example of where it's stored).

I think it would be good if we could use the internal naming convention,
so we don't have multiple ways to name widgets.  Also, naming based on
placement may be more natural for authorization.  Naming based on module
and class doesn't necessarily map well to authorization -- then
placement in modules of classes becomes very important.

The current naming convention may have to be extended to the "app" level
so that it could be accessed from everywhere.  

This is something to investigate.

3) I had an idea on processing the mapping differently.  Right now, we
have to find a list of regular expressions for a user based on group(s)
and then search for a widget across all of those regular expressions
until one is matched or all have been tested.

What if we had a pre-processing step on initialization of cumin-web,
like we do for the rosemary module or other things in Cumin?  What if
when each widget runs __init__, it looks up it's list of authorized
groups and stores it in self.authorized_groups.  Then, to check
authorization for a widget we have just a simple dictionary lookup on a
small group list.  Very fast.

Also, this fixes the "all wooly widgets are authorized" problem.  We
just treat an empty self.authorized list as "OK".

I may go ahead and try this in a local branch to see how it works.

Best,

Trev

[Trevor McKay]

Forgot one:

To harden this for general release, Cumin needs to check for the
existence of the map file on startup and fail to start if the map is
missing.   When running as a service, this will show up as a failed
service start.

There is an init-check section in cumin-web and cumin-data, the check
needs to go there.  My thought is that at least initially the feature
should be "on" or "off" based on the config file, and "on"
with a
missing file is a fatal error.

I did this to myself yesterday when I failed to copy the xml file to my
instance! :)

I probably will add this in today, too.

Trev

On Thu, 2012-03-22 at 08:09 -0400, Trevor McKay wrote:
>  Hello all,
>  
>    I played with the patch yesterday, and I think it's close to something
>  we can distribute in general from trunk.  Here are few items, in no
>  particular order.  Please share your thoughts.
>  
>  1) I prototyped a redirect solution, about to commit to the branch.  It
>  specifies a fallback page per group in the xml file.  When a user
>  touches an unauthorized widget, the fallback page is read based on the
>  group and a redirect is sent.  Not much code and it seems to work well
>  -- it solves the "login" issue for groups not authorized to see
>  index.html, which was the biggest issue.  Let me know what you think.
>  
>  (this can be improved slightly if the redirect from a login form looks
>  up the user's group first, before going straight to index.html, so we
>  don't get a double redirect, but that is minor)
>  
>  2) I wonder about the naming convention used in the xml file.  There is
>  already an internal naming convention that is used within a page.  It
>  names widgets based on their placement in the hierarchy.  It's used
>  internally in a few places to navigate, and it's used in generating URLs
>  (page_widgets_by_path[] I think is an example of where it's stored).
>  
>  I think it would be good if we could use the internal naming convention,
>  so we don't have multiple ways to name widgets.  Also, naming based on
>  placement may be more natural for authorization.  Naming based on module
>  and class doesn't necessarily map well to authorization -- then
>  placement in modules of classes becomes very important.
>  
>  The current naming convention may have to be extended to the "app" level
>  so that it could be accessed from everywhere.  
>  
>  This is something to investigate.
>  
>  3) I had an idea on processing the mapping differently.  Right now, we
>  have to find a list of regular expressions for a user based on group(s)
>  and then search for a widget across all of those regular expressions
>  until one is matched or all have been tested.
>  
>  What if we had a pre-processing step on initialization of cumin-web,
>  like we do for the rosemary module or other things in Cumin?  What if
>  when each widget runs __init__, it looks up it's list of authorized
>  groups and stores it in self.authorized_groups.  Then, to check
>  authorization for a widget we have just a simple dictionary lookup on a
>  small group list.  Very fast.
>  
>  Also, this fixes the "all wooly widgets are authorized" problem.  We
>  just treat an empty self.authorized list as "OK".
>  
>  I may go ahead and try this in a local branch to see how it works.
>  
>  Best,
>  
>  Trev
>  
>  _______________________________________________
>  cumin-developers mailing list
>  cumin-developers(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cumin-developers