Restrict access to view if $user == % (first parameter)

Could this possibly be done by creating a field called "logged_in_user" (with a hook?) and then adding a filter to it?

Filtering could work, but not perfectly: it would result in empty data; that is, in an empty list. But the "Disregarded" tab will still show on the profile page.

What you want is not to show the tab at all.

======

First, let's suppose your module doesn't exist.

How can an administrator disallow access to 'one/two/%/three' if % doesn't equal 67 or 56 ?

("disallow" = don't even show a tab, or a menu item.)

She can use a "validator". She goes to the argument settings form, then she picks the "PHP" validator, and in the textarea she types "return $argument == 67 || $argument == 56".

Now, to your module:

If all you want is to provide a "default view" with % restricted to current user, then I believe it's enough to export a ready made view where you typed the PHP into the right textarea. (This needs checking, though.)

Sometimes a module needs to provide a more complex validator for the benefit of its users. In this case you can write a validator class. The admin --that is, whoever builds a view-- is given the choice of whether to use it or not.

For example, the Organic Group module provide an "is % a group node?" validator.
For exmpale, the Flag module will provide an "is % a flagged object?" validator.

Maybe Views should provide an "is % the current user?" validator. Or an "is current user allowed to administer user % ?" Perhaps I'm missing something simple. Perhaps my long reply is unneeded, perhaps there's a completely different approach. Let's wait and see.

My most recent checking changed the access control mechanism to a plugin. You can now create a plugin that will tailor your access control appropriately. Be warned that there are two entry points to the access control: One where the view is loaded, and one where the view is not (via the menu system), so it can be a little more complex than you might like. But it's good, and it increased Views performance and flexibility at the same time.

Sure, look at includes/plugins.inc for the hook_views_plugins() definitions for the access plugins, and look at plugins/views_plugin_access.inc (and the variants) to get an idea for how they work. I believe the existing examples should be a good template for creating new ones.

@moofie: Maybe Views should provide an "is % the current user?" validator.

+1 for this concept. Since not everyone can write access plugins, so a default validator to check if the user is the logged user that's doing the viewing would be very desirable.

@merlinofchaos: You can now create a plugin that will tailor your access control appropriately.

-1 because currently I have many views that show user related content data I only want to be seen by the logged user. I understand the module creator could write an access plugin, but that doesn't solve the regular default created views with paths not depended on another module for the regular user.

I realize this is not a discussion, but how things are incorporated currently, but still I wish that beyond the current of choices of Unrestricted, By permission and By role there would be a forth option "By current user".

I hope my argumentation makes sense.

Kind regards,

Marius

Your argument makes sense in the "You have to do this for me" attitude that I am not fond of. Sorry, Views just isn't ever going to do everything for you. Sometimes features that seem obvious turn out not to be and you just have to live without them if you don't have the ability to write the plugins yourself.

merc: Because it has very little knowledge of your view, what you probably need to do is set the callback args to the arg() number you'll need, and you'll have to do this by taking the view path and breaking it up and seeing where you're arguments are. To be truly flexible you'll need to have a selector for which argument it should be as well.

its not very hard to do it :)
but there are two different ways:

first someone could write a access plugin
second there could be a additional views_plugin_argument_validate plugin

or
write a patch for views_plugin_argument_validate_user to extend it to only allow current uid, if wanted.

I'm attaching two patches here.

One patch adds an action for showing an access denied that can be used when an argument is not present or invalid.

The other patch extends the user validator with an option to limit to or exclude the currently logged in user.

I think a combination of these two patches might solve the core issue reported here - I wanted this functionality in a view I coded anyway I thought I could just as well create patches for it and share with you.

This would be more useful to Views as an access plugin.

The reason access plugins are valuable is that if you have multiple displays with the same path, the access plugin can be used to control *which* display is presented. Validators, however, cannot do this, as they are too late in the process.

So while this is useful, it would be more useful as an access plugin.

Subscribing. I would also find this incredibly useful.

@merlinofchaos: Interesting - didn't know that you could assign many views to the same path and have it select the right one based on access. I will try to get some time and write an access plugin - seems more usable.

Do you think the access denied validator action can have a place in Views anyway though?

Is there a reason this can't be included instead of as a patch? I can't get the patch to work (patching by hand.. tried four times.)

+ 1.

Attached is a new access plugin for views that allows you to restrict access based on the comparison of the logged in user and an UID argument.

For those of you that don't want to patch views, I'm also attaching a separate module that does the same thing.
@merlinofchaos: if you don't want to patch views with this access plugin, I can release this as a separate module.

There was an error in the views_user_access module, attached code fixes it.

duellj: This is very interesting. It is also very close, I think.

I believe this will fail if a uid is set via a default argument.

Take this case: I have a path, 'foo'. If I visit foo, I see 'my' foo. If I visit foo/51 I see foo for uid 51. This is accomplished by adding a default argument that provides the current uid if the argument is empty.

project.module has some fairly thorny code to accomplish this in its access checks.

I believe that, if we can get this working adequately, I will put this in Views.

I believe this will fail if a uid is set via a default argument.

It looks like it works if you set the default argument to be "User ID from logged in user". For "User ID from URL", it doesn't seem to work. For example, a block with "logged in user" access control shown on /user/51 will show the content for user 51 regardless if it's the logged in user. Desired behavior is to not show the block (since logged in user doesn't match argument).

I'll work on fixing this.

Actually, everything appears to be working. Got a false positive by the "access all views" permission :).

I reworked the patch a bit to match the naming of the other access check functions and to make the argument field required.

Is there a way to have a different error message for the options form? It would be nice to say something like "Please add an uid argument before configuring this access control" if there are no arguments defined yet.

You probably need to do an if() when presenting the select widget and provide a #type => 'markup' thing instead if there are not acceptable arguments.

Should I hold off on this patch until you've made that change? It seems like that nicety should go in.

You probably should hold off on the patch until I've made this change. It causes a fatal error if you use the access control without associating an argument. It'd be nice to make it so the user can't add the access control if there are no arguments, but I can just through a few if() statements in there for now.

Here's a new patch that displays a message if there are no arguments available, and denies access if argument hasn't been set.

Wouldn't we need a similar patch for 6-x-3.x as well?

+++ plugins/views_plugin_access_logged_in_user.inc	25 Mar 2010 19:36:11 -0000
@@ -0,0 +1,70 @@
+
+  function option_defaults(&$options) {
+    $options['logged_in_user_argument'] = '';
+    $options['logged_in_user_access'] = 1;
+  }
+  ¶

you should use option_definition. Therefore have a look at views_plugin_access_role for example. without this the export in views3 does not work.

Powered by Dreditor.

There was a patch in the queue, which allowed to send dynamic arguments to the access callback.
I think this would make the code much cleaner and faster, because you wouldn't have to load the view.

We are testing this patch now and need this functionality. Subscribing.

you should use option_definition. Therefore have a look at views_plugin_access_role for example.

It looks like view_plugin_access* only use option_definition in views3. I'll reroll the patch into 6.x-3.x that includes option_definition(), but I think the patch in #35 is ready for 6.x-2.x

Here's the patch for 6.x-3.x

The patch in comment #35 worked for us in views 2 well done.

It looks like view_plugin_access* only use option_definition in views3. I'll reroll the patch into 6.x-3.x that includes option_definition(), but I think the patch in #35 is ready for 6.x-2.x

I don't think so, the option_definition api is there since ever. Have a look at the other access plugins.

Subscribing.

In reply to #37, just in case anyone needs it, the patch for dynamic access arguments is here: http://drupal.org/node/644008

I like this idea, would remove the need to write custom access plugins for many use cases.

Hi,

I had the same use case and wrote a module before finding this post. It's less complete than duellj module because it assumes the user ID is the first argument (so you can't select the argument in a list). I'm attaching the module here...

Subscribing

Is #35 the one to review? Maybe we could bring this thread back to life.

subscribe.

I also have little confused this access control issue in views.

I recently made some views for the member system of my web site. I use these view as a block on the path /users/user-name. These views will release info about:

1. User profile (core)
2. content profile (content type)
3. User's collection (flag)

1. <- To my surprise, with this setup, the user can see other's drupal profile directly. This is serious privacy violation.
2. <- Only content profile is protected (I guess this is because Views and content access are integrated very well).
3. <- They can also see other's flag info.

Currently I do this will PHP validation to arguments (like many posts above). However, should views take care of access control or let other module do this with hooks?

If anyone knows any document related to this issue, please let me know. Thanks.

I want to have a tab on the user profile which is a view. But this should only be viewable to the user in question.

For example, "user/%/myview".

As far as I can tell, this isn't possible using the current permission and role-based access checks. What is the best way to go about this? The only thing I can think of is to create the path in a module using hook_menu() and then in the callback render the view. Then I would have full control over the access callback. But before I go down the custom code route, I wanted to check that it isn't possible using just views. If it isn't, it might be a feature worth considering to have "current user matches contextual argument" as an access option.

I am using Views 7.x-3.x.

I created my own module with a views access plugin. Thanks to the people who supplied patches in this thread. I think this is probably a cleaner way of doing it, although it's a shame you have to manually set the view args based on the view path and the current path, but it doesn't seem that any of the existing views code can be reused for that.

@Rob230 can you post your module?

It's quite basic. I based it on the patches other people provided.

Edit: actually that has a bug in it. It doesn't work for blocks. You just need to add:

$this->view->set_display($this->display->id);
$this->view->init_handlers();

to the access function in views_plugin_access_current_user.inc.

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue