i created a page view which i am trying to limit to only be visible within the group.

i thought perhaps i would try the views access handler for OG Permission - even though this won't be what i need since this would allow anyone with that access in any group to have access to the view which should be only "in" a specific group.. but thought i would try it out anyway

i set view access as: og permission -> create survey content

but my view is still visible to anon.

to be sure this was an og access issue i set view access to simply: permission -> create survey content and sure enough anon no longer has access

as a final test i actually tried to add a survey as anon with node/add/survey and i got this exception:

Fatal error: Declaration of OgSelectionHandler::getInstance() must be compatible with that of EntityReference_SelectionHandler::getInstance() in E:\wamp\www\boma\sites\all\modules\og\plugins\entityreference\selection\OgSelectionHandler.class.php on line 7
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

weekbeforenext’s picture

I'm having a similar issue in version 7.x-2.0-beta1. It seems that I cannot restrict access to a view using the OG Permissions option.

zipymonkey’s picture

Component: og_access.module » og-context

I'm also having the same issue (7.x-2.0-beta1) but I believe the issue is in the og_context_plugin_access_og_perm::access function, which does not appear to be called at all so the og perms are never checked when the view is rendered.

No ideas on how to fix this.

C-Logemann’s picture

The current code is working for me on views blocks but not on views pages. This can be a security problem if there is a forgotten views page display where the access is controlled by the og_context permission handler.

When I add the get_access_callback() function (see attached patch) the access to the page is controlled and denied by default. In this way a forgotten views display is safe even for user 1. I have successfully tested the retrieval of og permissions without og_context() with a hardcoded gid. But in my setup og_context() can't get the gid context of the views page. Maybe I can't see a needed views or og_context setting or there is needed some code to get the gid in another way. Maybe we can add another setting for the permission handler to retrieve a node id from url and look for the related gid in the database if the views page path provides this. I think a better way would be a context handling for views pages on a lower level. But I have currently no idea how to realize this.

edit: typo

GuitarHandheld’s picture

Status: Active » Needs review

Great post!

zipymonkey’s picture

Maybe there needs to be a new og_context_handler for page views? For whatever reason I don't think any of the og_context_handlers are called when loading view page with og contextual filters.

amitaibu’s picture

I'm not clear about the patch, as we already have og_context_plugin_access_og_perm::access() -- why do we need it?

C-Logemann’s picture

I had the same problem as the others and searched a little bit at the views API:
http://api.drupal.org/api/views/plugins%21views_plugin_access.inc/class/...

I do not understand everything related with the views permission handling. I just figured out that the access($account) doesn't work on views page display and so everybody can access. With the additional get_access_callback() we can handle this and block access by default. But my patch doesn't help with the og_context() problem as described above.

Edit: I want just say that I am also confused about this two permission functions in the views API. But because of the good work of the views maintainers I believe there is a good reason for this.

amitaibu’s picture

Status: Needs review » Fixed

Ok, I see there's also a views_plugin_access_perm::get_access_callback()

Committed, thanks.

C-Logemann’s picture

Assigned: Unassigned » C-Logemann
Status: Fixed » Active

Thank you @Amitaibu for committing my patch. Now the access to a page display is denied by default. But currently the og_context() is still not retrieving the group ID and no TRUE-Situation can be reported by the og_user_access() function to allow access.

I think the most views pages for organic groups are dealing with the group ID for using this in contextual filters. So I will follow my plan to get one situation working: Getting the group ID from the arg() function.
For this I will modify the permissions settings where the arg() position of the the group ID can be selected. Next I modify get_access_callback() to deal with two situations. If the arg() setting is used the og_user_access() will be called directly. Else we first try to get the group ID from the og_context() function.

C-Logemann’s picture

Assigned: C-Logemann » Unassigned
Status: Active » Needs review
FileSize
3.19 KB

I can't call any function inside views_plugin_access::get_access_callback( ) so I created in the module file a new function _og_context_views_page_access() to handle this.
When using og_context() I get a WSOD because of Memory and with 512MB I get an server error 500.
I have deactivated with a comments which can be deleted before committing.
With the attached patch the access of a views page display can now be allowed via arg().

weekbeforenext’s picture

I'm working on a views access plugin for og roles and I've had similar issues. - http://drupal.org/node/1665296

I posted in the Views issue queue to see if the problem was with the way I was writing the plugin and I got a quick response. - http://drupal.org/node/1744996#comment-6381350

It hasn't solved the WSOD issue, but at least the access callback is recognized. I've made some changes to the og_context.module file. I think there may be an issue there that is causing problems, but I'm working on getting a debugger/profiler up and running to see if I can pin point the issue.

Hope this helps.

UPDATED: Nevermind, I see you fixed the callback function. Sorry, about that.

weekbeforenext’s picture

C_Logemann, your work helped me a lot. I pulled your code to identify the gid from a view page and put into a separate function so that I can use the same code for my role based access plugin. If you would like to take a look, I have posted it here: http://drupal.org/node/1665296#comment-6384578

Thanks for your contribution. It was very helpful.

generalredneck’s picture

Adding a cross-link here. For those looking for the OG 1.4 fix, look at #1784570: Views permission handler does not limit access

BassistJimmyJam’s picture

I have a few thoughts about the patch in #10:

It would be ideal to use context in the callback to determine the group, since the views plugin is provided as part of og_context. However, calling og_context() tries to get the current menu item which will try to run the access check and lead us into an infinite loop. We would have to find a way around that in order to use context.

Barring that, the site builder should be able to select from a list of contextual filters defined on the view. Not everybody building a Drupal site is a developer and understands things like zero-based arrays. This also allows the argument to come from a default value (such as the current user) rather than a hard-coded index in the path.

btopro’s picture

FileSize
3.02 KB

Please accept the patch in #10 into the 7.x-2.x-dev build of this project. I just spent 3.5 hours hunting down whatever issue compounds without this patch which lead to EVERY view on a client site not being able to save. I'm not sure why that would be the case as I've used OG 2.x for awhile now and haven't experienced this issue but I assure other people that they won't want to run across this. There seems to be some kind of memory leak / infinite loop that can occur with the current method of assessing the get_access_callback of class og_context_plugin_access_og_perm extends views_plugin_access.

I'm not sure if this is a newer thing as a result of upgrades in the Entity / OG stack in general or if it has something to do with Entity Tokens / Entity references but as I said, this took way too long to track back to this exact issue so please give it some review.

In case anyone is wondering what module's were in use to trigger this crippling issue I've attached an associated .info and .make file curtesy of Profiler Builder.

btopro’s picture

amitaibu’s picture

Title: Views permission handler does not limit access » Wsod using OG access permission in Views page display
Assigned: Unassigned » amitaibu
Issue tags: +OG 2.x release blocker
FileSize
57.63 KB
4.87 KB

I've cleaned up code, and show the the "Argument position" only on Page display.
Please test.
og-access.png

amitaibu’s picture

Status: Needs review » Fixed

Committed, thanks.

generalredneck’s picture

You may consider porting this back to 7.x-1.x-dev. Should be the exact same code. See #1784570.

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

maen’s picture

Issue summary: View changes

Hello @ all,

with og, og_context and og_access_control 7.x.26 enabled with drupal 7.28 I try to use views calendar explained from book.

But there's nothing to see.

If I only use the relationship with "OG membership: Group Node from OG membership" and permission "show published content" I can see the content from the private groups for each member as it should be.

But the content of the user without a group reference is hidden at all. Nobody exept superadmin can see it. But because these are private dates written by the user it should be seen by him.

So the og_access_control goes too far by hidden the ungrouped content.

When I remove the relation from above and take the relation "author" and filter I can see it.

So what can I do against this behaviour?

THX in advance,

maen

joshuautley’s picture

#18 Using the "OG Permission" prevents me from access the path to my view when adding a link to the view in a menu.

Any thoughts as to why?