I've brought this up in IRC but never saw any response, but since I've been away a lot lately you may have answered and I didn't get the response. If so, please disregard.

The node validator has an option to check to make sure that the user has access to the node as part of the validation process. However, if the user does not have access then the action to take if the node is not validated is what gets taken. However, I think it would be nice if it was possible to show an access denied page in the case where the the argument would otherwise validate except that the user does not have access.

I know how I could write a custom handler or validator to get this, but was just thinking that maybe this should be the default behavior.

Comments

merlinofchaos’s picture

merlinofchaos commented

Hmm. Right now validation is pretty much a true/false thing; this changes validation to a 3 state system which may have fairly sweeping consequences, plus add more gunk to the UI. This isn't a bad idea, mind, but it may not be doable in the short term.

aclight’s picture

aclight commented

Actually, I wasn't necessairly proposing that validation change to a three state return, but instead modifying views_plugin_argument_validate_node::validate_argument() to look like this:

        if (!empty($this->argument->options['validate_argument_node_access'])) {
          if (!node_access('view', $node)) {
            return drupal_not_found();
          }
        }

Quick testing of this code seems to work, but I agree that this change in behavior might have undesired consequences.

If you don't want to change the current behavior, what about including another node validator with views that handles this particular case in this manner. I could submit a patch for that easily. I can just as easily add this code to project.views.inc, but this would not be project* specific at all and might be something that other developers would find useful.

merlinofchaos’s picture

merlinofchaos commented

You can't call drupal_not_found() from within an argument validator unless you are absolutely certain that it will never be used as secondary content. i.e, panel pane, block, etc.

aclight’s picture

aclight commented

Ah, I see. So writing my own validator to do this is also a bad idea, I suppose. Where would you suggest I do this from then? Would it be safe to add an additional "Do this if the argument does not validate" option that calles drupal_access_denied()? I'm guessing that also would cause the same problems.

merlinofchaos’s picture

merlinofchaos commented

Yea, this is unfortunately far more complicated than I want it to be. Also I'm annoyed that I forgot that 403 is likely to be a needed response.

I'd be ok with a hack where maybe you set some kind of flag on the view and the page display is smart enough to read that flag and 403 instead of 404; I think that's pretty much how 404 works anyway, so maybe an overload there would work and the other displays would behave the same way; as long as it goes down the 'not found' path, argument validators can be the thing smart enough to set the access denied flag.

moshe weitzman’s picture

moshe weitzman commented

related to #284810: Incorrect 404 handling when argument validation fails

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Fixed

You can now write access plugins, though please note that they happen very early; the view is never loaded and they don't know a lot about anything, but hopefully you can use them to solve this.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.