Skip to content
This repository

view_execution_permitted() when view does not exist? #299

dairiki opened this Issue · 7 comments

4 participants

Jeff Dairiki Michael Merickel Chris McDonough Robert Buchholz
Jeff Dairiki, request, name) currently returns a true value if there is no appropriate view registered for the context. I'm not sure whether that is the intended behavior or not (so I'm not sure whether this is a bug report or a feature request.) I would argue that "view exists and is permitted" is a more useful predicate than "view execution permitted or view does not exist".

In my use case — which I'd guess is not uncommon — I'd like to determine whether the current user can execute a given view on a given context without knowing a priori whether that view is even registered for that context. (The result of the check determines whether an entry for that view will appear in an admin nav menu.)

Currently, AFAICT, the only way to determine whether a particular view exists using Pyramid's public API is using pyramid.traversal.traverse, which seems awkward and overkill. Have I missed a better way?

Michael Merickel

If this is unintentional it can be fixed by querying the registry for IView instead of ISecuredView, then if no IView is found returning Denied. If the IView is found and it's not an ISecuredView, return Allowed, otherwise perform an actual security check.

@mcdonc, is this behavior intentional?

Chris McDonough

Can you help me understand the situation where you don't know if the view exists or not before trying to do the security check?

Chris McDonough

Actually scratch that, I can imagine a case. But can you help me understand what distinction you're trying to make when the thing returns "nonexistent" vs. "denied"?

Jeff Dairiki

Main response

I'm not sure that I do care about the distinction between “nonexistent” and “denied”. The point I was trying to make was only that it seems incorrect — or at least non-useful — for view_execution_permitted() to return a true value when the view does not exist. (Okay, fine, you’re not going to get a 403, but you are going to get a 404.)

Ancillary comments

The use case was the construction of an admin menu for a CMS-ish system. There were a list of menu entries ("Edit", "Add Page", "Rename", ...) each corresponding to a specific view name. Not all contexts supported all those views — some contexts did not have an 'add_page' view, for example — and not all users were permitted to perform all views. I wanted to display only those menu entries which the user was able to perform.

I’ve since refactored the admin menu configuration code. At present, the above use case is no longer an issue for me. (It’s probably still a valid one.)

I can also see a sticky point about this use case: What I was really interested in was whether a view could be executed by the user with request attributes that might differ from those of the current request. E.g. I might want to know if the user can perform a GET even though the current request is a POST. I can see that this is outside the domain of

Robert Buchholz
rbu commented

Returning Denied if no view is found sounds like a more sane default than allowing access to anything unknown.

Chris McDonough

@mmerickel and I discussed this in IRC and I think we decided that the view_execution_permitted callable should raise an exception when asked for a view name that doesn't exist.

Chris McDonough

(which exception? i dunno)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.