Hi,

let me try to explain what I have come to realize is a serious flaw in the way OG User Roles works in conjunction with OG module.

On my site, documents and articles can generally be submitted only through "contributing users". However, any user who joins a group will be granted the "contributing user" role for that group only (thanks to OG User Roles module), hence being able to post documents and articles into that group.

Users goes on and creates a document for group "A". He/she will not see an audience checkbox, instead he only sees "audience: Group A". User submits the document and later decides to edit the document. NOW, upon editing, user is exposes to the audience checkboxes! Say he is a member of group A and B... He may choose to post the document into group A and B, or into neither.

The latter is the problem: Through this mechanism, ANY user - regardless of his role - is enabled to actually post to the public section of the site by simply editing his group content and removing all audience checkboxes!

In OG module, you can choose to set the audience to required instead of optional. That would fix this problem, however it would disable all regular contributors to post content to the public section of the site.

I hope I successfully depicted the problem - any ideas on how to solve this? It really messes up the entire permission system of my site. :(

Regards
Patrick

CommentFileSizeAuthor
#4 og.module.5.x-3.x-dev.patch990 bytessomebodysysop

Comments

Coyote’s picture

Coyote commented

I think this is largely an Organic Groups issue, and not og_user_roles.

It appears that the group's creator (and this is OG functionality, not og_user_roles) is _always_ allowed to set the audience of any posts made to their groups.

Perhaps that's okay when group creators/admins are always trusted users (i.e. site admins or moderators), but it's certainly _not_ okay when, for instance, you allow any registered user to create user groups.

One of the frustrating things about working with OG at all is that there seem to be a lot of assumptions made regarding who can post what, and in what place, or what administrative abilities to assign to group owners or moderators. og_user_roles fixes a lot of that by allowing you to assign roles based on group context, but the whole OG system is seeming more and more flawed to me.

somebodysysop’s picture

somebodysysop commented
Category: bug » task

This is an Organic Groups issue. See these issues where it is discussed:

http://drupal.org/node/130601
http://drupal.org/node/164070
http://drupal.org/node/183245

You will see in the issue I initiated, that this OG feature is "by design".

I wrote a patch to resolve the issue: og.module.5.x-3.x-dev.patch (http://drupal.org/node/178874). However, I've only tested it with TAC/OG Access Control turned on. Unfortunately, this patch is not part of the distribution since that feature is by design (i.e., whether og user roles is installed or not). You should find this patch here: http://ftp.scbbs.com/pub/drupal/TAC_OG/

Try the patch and see if it helps.

Note that user christofano also made a suggestion: http://drupal.org/node/130601#comment-282515

Rhino25782’s picture

Rhino25782 commented

Thanks for the links.

Originally I thought it was an OG issue, too - I even had started filing an issue in the OG module section. I certainly see the connection between the problem I am having and the one that is being discussed by Moshe Weitzman et al.

However, the fact that in the situation I described above, users with specific OG user roles (to contribute content to a group) are able to _uncheck_ all audience boxes really is an OG user roles problem. Without OG user roles, it would be perfectly fine (i.e. "by design") that the content types you are allowed to post can either be posted to your subscribed groups or to no group at all (in "audience required" is unchecked).

So there is two distinct problems here:
1) What groups to show in the audience section of the Edit form (OG problem)
2) Users being able to retrospectively uncheck all checkboxes (and subsequently escalating their user roles to site-wide roles! => OG user roles problem!).

Any thoughts on this?

I am testing the patch you provided, Ron, and it seems to solve the problem for me. Thanks for that. Still I'd like to stress that, without this being patched either in a OG module release or OG user roles release (in some way), this is a group security issue that is largely affected by OR user roles.

somebodysysop’s picture

somebodysysop commented
StatusFileSize
new og.module.5.x-3.x-dev.patch990 bytes

So there is two distinct problems here:
1) What groups to show in the audience section of the Edit form (OG problem)
2) Users being able to retrospectively uncheck all checkboxes (and subsequently escalating their user roles to site-wide roles! => OG user roles problem!).

Any thoughts on this?

I've spent quite a bit of time thinking on this. This is what I attempted to resolve without a patch here: http://drupal.org/node/130601. You are right. The very nature of OG User Roles makes it an OGR problem, but the solution as far as I'm concened, lies with the OG module. Unless you can demonstrate another way to resolve it, this remains my conclusion.

I am testing the patch you provided, Ron, and it seems to solve the problem for me. Thanks for that. Still I'd like to stress that, without this being patched either in a OG module release or OG user roles release (in some way), this is a group security issue that is largely affected by OR user roles.

This exposure is perhaps the biggest security issue I've ran into with OGR since getting it to work consistently.

As I pointed out to the OG isue moderator here: http://drupal.org/node/130601#comment-218695, all I wanted to do was

display the same thing (audience defaults to current group, no checkboxes) on "edit" form as is displayed on "create" form.

This is the resolution to the security issue in my mind. But, the OG moderator does not see it the way I do. Hence the patch.

It's not that I refuse to do anything about this problem. I have tried, and what you have is my resolution. If someone has a better approach, please share it with us.

Rhino25782’s picture

Rhino25782 commented

This is the resolution to the security issue in my mind. But, the OG moderator does not see it the way I do. Hence the patch.

Yep - I can see where both of you are coming from, although I'd rather want to see your patch applied for the sake of a secure permission system than not applied for the sake of a little bit more usability as regards switching around audiences (which in my scenario rarely ever happens and if it does, it can very well be managed through site admins).

At the end of the day, it seems that more flexible control through OG over when what kind of audience boxes are shown to what kind of user are the ultimate solution. As has been pointed out somewhere (possibly by you), OG currently makes too many assumptions about use cases.

I see this is being discussed at multiple ends so should we close this issue?

somebodysysop’s picture

somebodysysop commented
Assigned: Unassigned » somebodysysop
Status: Active » Closed (fixed)

Sure thing.

somebodysysop’s picture

somebodysysop commented
Version: 5.x-2.5 » 5.x-3.1

I've finally addressed this issue here: http://drupal.org/node/258976#comment-850935

OGR now has a new function: og_user_roles_user_access($string, $gid, $uid). It is called during nodeapi('validate') and will make sure a user has permission to post in all groups that are listed in his group audience.

tborrome’s picture

tborrome commented

Hi, is this fixed in og_user_roles-5.x-3.2 ?

When I edit a node from a group, I still see audience check boxes for all the user's groups. (original issue mentioned above.)

Works fine when I create a node, only the paricular group is shown as audience and no check box. But during Edit, a list of checkboxes for all the user's groups are shown.

somebodysysop’s picture

somebodysysop commented

This issue thread explains where we are on this.

tborrome’s picture

tborrome commented

please clarify. the issue seems to be closed as of 5.x-3.1 but i still see this behavior in 5.x-3.2. should i apply a patch on 5.x-3.2 to get this to work? the patches available on this thread seem to be for 5.x-3.1 only. thanks!

somebodysysop’s picture

somebodysysop commented

Again: This issue thread explains where we are on this.

There is no "fix" for this issue. The security issues have been resolved as of OGUR 5.x-3.2. See #7: http://drupal.org/node/187097#comment-850963

Please re-read this thread carefully. This issue is closed.