You can clone with
Pyramid.security.view_execution_permitted(context, 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".
Pyramid.security.view_execution_permitted(context, request, name)
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?
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?
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?
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"?
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.)
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 pyramid.security.
Returning Denied if no view is found sounds like a more sane default than allowing access to anything unknown.
@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.
(which exception? i dunno)
raise exc if view_execution_permitted invoked on non-existant view