Here is what I see:
- The way Pyramid does everything super flexibly (URL structure, the view
callables, the role concepts, and the permissions as you said it) can make
it very complicated to do otherwise simple things, such as making a
request.route_allowed()...
- If request.route_url() exists and works, why can we not make
request.route_allowed()? I understand that one route *may* point to
multiple views, but that mechanism is implemented already, since Pyramid
can decide what to do on every incoming request.
- The *only* thing what I can imagine is not obvious from a request and a
route_url is the GET/POST, etc. kind, since the user might want to change
that between requests. (For example calling a form, etc.).
So why can we not make a simple request.route_allowed(**kwargs,
method='GET') method, where kwargs would be the same as for route_url()?
Zsolt
On Saturday, 12 November 2016 00:40:17 UTC+1, Mike Orr wrote:
>
> On Thu, Nov 10, 2016 at 12:48 PM, Zsolt Ero <zsol...@gmail.com
> <javascript:>> wrote:
> > Hi, I'd like to do the simplest possible thing in Pyramid / URL
> Dispatch,
> > yet it seems almost impossibly hard to do it.
> >
> > So it's the super common case of having a menu, and I'd only like to
> insert
> > menu items which are available for the current user.
> >
> > I'm looking for a function to fit in this usage:
> >
> > {% macro nav_item(request, route_name, text) -%}
> > {% if request.view_execution_permitted(route_name) %}
> > <li>
> > <a href="{{ request.route_url(route_name) }}">{{ text }}</a>
> > </li>
> > {% endif %}
> > {%- endmacro %}
> >
> >
> > My problems are the following:
> >
> > 1. view_execution_permitted doesn't work like this, unlike other
> security
> > functions, for example request.has_permission(). Why?
>
> There seems to be a logic problem here. Routes aren't
> authorization-significant entities; a route is just a URL pattern.
> Users belong in roles/groups (Pyramid calls all of these "principals"
> -- defined by the "groupfinder" callback in the authentication
> policy). Principles have permissions -- defined in the ACLs others
> have talked about. A simple URL Dispatch application may have just one
> ACL for everything: a root factory defined at startup sets all the
> permissions that all the pages need. A more complex URL Dispatch
> application may have different roots for different parts of the
> application (different view configurations), and each of these can do
> their own private traversal to sub-objects. But it's easier to start
> with a single root for the entire application. Each request will have
> its own instance of that root, which is the "context" available to the
> view and the authorization system. Finally, the view configuration
> ties all of these together: the view, the route, the root factory with
> its ACL, and the permission required to execute the view. The reason
> all these are separate is to keep some independence between the URL
> structure, the view callables, the role concepts, and the permissions:
> so you can design each one autonomously to its best structure, and you
> can change one (within limits) without affecting the others.
>
> So the answer to your question is, what determines which menu items
> should be displayed? Not the routes, the *roles* (principles). The
> roles imply permissions, and r'equest.has_permission' tells whether
> the user has that permission (i.e., can execute the views that require
> that permission). However, there's no formal listing of which routes
> go with which permissions; that's all tied up in the complex view
> confugrations. But you should know which permission each page
> requires. So you should do a (in Mako syntax which I'm more familiar
> with) '% if request.has_permission("foo_permission"): <a
> href="${request.route_url('foo_route')}">text</a> % endif'. I have one
> application with permissions and I use 'pyramid_layout', so I define
> several boolean attributes in the layout object ('can_do_this',
> 'can_do_that'), and use those to decide which menu items to display in
> the site template. For links in individual pages, the view sets
> similar booleans. Actually, I don't always use booleans because I like
> to generate the URLs outside the templates, so I use None to indicate
> no URL (no link), or I give a list of permitted URLs that doesn't
> include the unpermitted ones.
>
> If you need to do something dynamically (e.g., user-defined URLs and
> permissions that the developer doesn't know about), then studying
> Kotti might be useful, because it allows site admins to define users
> and roles and pages and link them together.
>
> So I don't think you'll need to ask whether a route is permitted to a
> user; that concept belongs in the principles and ACLs. But there may
> be something I'm missing. As for 'view_execution_permitted', I've
> never used that and I'm not sure it's useful for application
> developers, especially in a URL Dispatch application. It may be
> something Pyramid uses more internally. The fact that it requires a
> view name is a red flag. Routes kind of replace view names in URL
> Dispatch. Traversal uses view names extensively to choose between
> multiple views for a resource. URL Dispatch uses mostly the route name
> to choose a view, and specifying a view name could accidentally make
> the view configuration not match the request.
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/eef28c70-7bbe-40f7-b1cf-d4eff8b07550%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
