Views does not check hook_field_access()?

Views provides its own role-based permissioning, doesn't it? Does it skip hook_field_access()?

Right you are, this was neglected from the field handler. I've committed a fix, but I would appreciate it if someone would verify that it functions properly: http://drupalcode.org/project/views.git/commit/807060035975999c8d963bdab...

$field takes the full field object... But this change still doesn't do it. Hmmmmmm.

Correction, the above patch does work, but it doesn't work for individual "View own" permissions.

I'm not sure how we would accomplish this for individual authored fields though, but I'd say this is good for the time being.

Hmmmmmm, is there anyway to have the field access checked for each item that's being posted rather then just once on the field?

This patch just fixes it for the whole table view, but not for individual entities.

Hmmmmmm, is there anyway to have the field access checked for each item that's being posted rather then just once on the field?

Shouldn't this be done when you view a formatter?

Right now, Views checks only on a per field basis. In previous Drupal there was no ability to have access control more granular than that, except through a mostly broken field permission module.

It is entirely possible that we need to have a big/small field access check.

1) Can you access this field at all? No? Ok, remove the column. Maybe? Ok, check per field.
2) Can you access this field on this row? Problem: Rows are not necessarily tied to entities. Things get ugly there when you start using group by.

subscribe

Commited the patch, let's actually implement the logic from http://drupal.org/node/1124298#comment-4390396

Subscribe.

subscribe

Isn't this remaining task a real duplicate of #1135002: Hide table column if it's empty?
Some feedback would be cool

Earl agreed that with hide table columns linked above everything is need exists.

subscribe

@dereine I don't think this is a duplicate of #1135002: Hide table column if it's empty, it's an access control issue rather than a display issue.

It looks to me to be more like a duplicate of #1273534: Pass entity when calling field_access though. If we're to implement the recommendations of #9, the finer grained access check will need to use field_access with an $entity passed in.

Yes, I mentioned on IRC that the real issue is #1273534: Pass entity when calling field_access.

I looked into this, and I think there is a critical bug here that is independent of #1273534: Pass entity when calling field_access.

When Views displays a field, it calls field_view_field() to do it. That function already takes care of invoking hook_field_access() internally (with the entity passed along). It then puts the result of that access check in the #access property of the renderable array that it returns.

The problem is that in most cases, Views does not render the entire array it gets back from field_view_field(); rather it goes in and grabs the children to render. This results in #access getting ignored.

The attached patch should hopefully fix it. With this patch applied, the latest Views and Field Permissions code now work nicely together.

It still may be useful to do #1273534: Pass entity when calling field_access on top of this, for a number of reasons - relying on the method here for field access means that the field itself isn't excluded from the view, but rather it's treated as an empty field (so you'll still see field labels and such, unless you've configured the view not to have labels for empty fields). But this patch seems like it's correct either way, especially since there are other ways #access can get set (and it's important for Views to respect that).

I believe this is a critical bug because of the access bypass issue. In practice, there might not be any production-ready code that actually triggers this problem; plus, since Views only has an RC release right now (not a 3.0 release) we can deal with it in the public issue queue rather than via the security team. However, as a potential security issue, this probably does need to get fixed before Views 3.0.

Thanks for the patch. You are right, this is definitive a critical issue here!

Commited as it is to 7.x-3.x

I wouldn't have considered this a critical bug. Views is a query builder with multiple inbuilt access controls and the user is specifically requesting field data by adding the field. A major feature request maybe...

Anyways, cross posting to a followup issue #1848380: Bypass hook_field_access() restriction.