Yeah I knew what you meant about overriding the controller; was just stating where I'm at so far. Your last point about inheriting from existing classes is very interesting and for some reason something I didn't really consider! Either way I'm still thinking
there should be core changes in Orchard to support view permissions and close that security hole. Having authorization events on content handlers seems a logical and consistent way to do things, certainly much easier than IAuthorizationEventHandler (where
unfortunately I had to replicate a lot of code to plug in the per-item permissions).
Actually instead of a Driver, you could have a Handler that will nullify *all* display shapes if a permissions check fails. But it's a pretty ugly way to do things; and something I pointed out elsewhere is that a lot of code will still run in those circumstances.
An example would be your view count feature; it would register an item view even though it didn't get displayed!
I can see your point about 404; but realistically the admin areas already use HttpUnauthorized - what actual use is it to know that there's a URL called /Admin/Contents that I'm not allowed to access?
Where the 404 could actually produce a detrimental user experience, is if someone's session has timed out and they try to access a page that's normally there; suddenly they hit a big 404 instead of just being prompted to log in.
Putting it another way: can you outline a specific case where it would actually be a
problem for someone to know there was a "secret Url" that they couldn't access? Because if so, then all the existing controllers should be changed to 404 instead of unauthorized :)