Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.when I unpublish content (including blocking a user and unpublishing their content), it still shows up in the activity streams.
I get this on my real site running commons3.3 but just verified it on out of the box 3.5
-create and publish a post in a group
-it show up in status stream
-unpublish the node
- it still shows up in status stream - including for just a generic non-admin user who should not be able to see unpub content
Here is a screenshot where I have unpublished a node called "2nd post ever". Now the node is gone from the "active in this group" block and from the listing of all posts in the main block, but is still there in the activity stream. And in most other activity stream blocks/views.
I don't know how to fix this... I've checked the activity stream views and they seem to filter on "content: published or admin", but it's not actually filtering. It's getting over my head with the target nodes being entity references.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 2159245-message-access-comments-14.patch | 2.45 KB | japerry |
| #5 | Screenshot_12_18_13_2_53_PM.png | 61.57 KB | japerry |
| activity_stream_view_filters.png | 16.51 KB | WebSinPat | |
| activity_stream_unpublished_content.png | 65.59 KB | WebSinPat |
Comments
Comment #1
ezra-g CreditAttribution: ezra-g commentedThanks for this detailed report. I'm unable to reproduce this issue on a fresh installation of Commons 7.x-3.5 or the latest Common dev.
Are you using any node access modules? Are there other customizations that you've made to your site (eg, overidden features) that might be related?
In the future, please contact the Drupal security team privately with reports about potential security issues in Commons so that we can work with you to resolve them according to the Security Team's disclosure policy. In this case, leaving the issue published since we're not able to reproduce.
Comment #2
WebSinPat CreditAttribution: WebSinPat commentedthanks, ezra, i didnt realize this was a potential security issue. will keep that in mind in the future. and pls feel free to close this as neccessary.
That said, I was able to reproduce this on a *fresh install of 3.5* I don't believe i've made any changes to my 3.5 instance other than creating a user and some content.
when i search on the module page for "access" none of the modules that come up are enabled.
there are a number of features that show up as overridden or conflict, but I don't think I've caused any of that, it seems to be out of the box somehow.
"commons miscellaneous configuration" is overridden and seems to be mostly variable name changes
"commons notify" is overridden with what looks like some messages configs, which might be relevant.
Should I revert these features?
(I don't get why features would be overridden on a fresh install?? all i did was unzip the tarball, create a new database, and then update.php)
Comment #3
ezra-g CreditAttribution: ezra-g commentedAre you able to post a screencast showing steps to reproduce starting from installing Commons 3.5?
Feel free to continue the discussion in #drupal-commons on IRC as well :).
Comment #4
WebSinPat CreditAttribution: WebSinPat commentedi'm a total irc noob. i think i've logged in to the channel, and that's as far as i've gotten ;)
of course the features were stuck overridden and would not revert, so that direction was no help.
so i'm working on a reinstall with screencast.
Comment #5
japerryI can reproduce, and it works as designed. See following screenshot for further clarification:
Basically, if you created the node -- you'll see it in your activity stream. If you're an administrator (aka you can see unpublished nodes) you'll also see it in the activity stream, presumably so that you can see a group was created and publish it.
Marking as closed - works as designed.
Comment #6
WebSinPat CreditAttribution: WebSinPat commentedthanks @japerry for that info.
on my production site, i definitely have regular users (not admin, not the users that created the node) able to see unpublished content in the activity stream.
So I'm setting back to "postponed" while i can see if i can reproduce on my fresh install.
Comment #7
japerryThanks, definitely also check to make sure that users can access the node if it appears in the activity stream.
Commons isn't doing anything special here, its just using the filter that comes with views. If users who aren't able to access pieces of content can see them in the activity stream, that'd seems like an issue inside views.
Comment #8
WebSinPat CreditAttribution: WebSinPat commentedok i have indeed been able to reproduce on stock 3.5.
The problem is specifically around unpublished COMMENTS (not posts) in activity stream.
-create user2 and user3
-admin creates post in engineering grp
- user2 comments on post
- user3 comments on post
- user2 and user3 comments are visible in activity stream as expected
- admin cancels user3 account - disables account and unpublishes content
- user2 still sees user3's comment notice in the activity stream, though the comment is unpublished and user2 cannot see the comment if they click on the link in the activity stream
ditto if the comment is simply unpublished by admin without blocking the user.
Comment #9
WebSinPat CreditAttribution: WebSinPat commentedI am still able to reproduce this on fresh 3.8 install.
(there was a concern when i first posted this issue that it was a security issue. might that still be the case??)
Comment #10
ezra-g CreditAttribution: ezra-g commentedBumping to the 3.9 radar to re-review.
Comment #11
ezra-g CreditAttribution: ezra-g commentedHere's what I am able to reproduce:
On a group-specific activity stream (eg 'groups/boston'), an activity stream entry about a new comment in the group's activity stream (eg, "site admin commented on How to create a veggie burger in the Boston group.." is not deleted when the comment is unpublished.
However, neither the title, message or URL of the comment are revealed, and the activity stream message *is* hidden when the node is unpublished. Based on that, this seems more like a bug of stale information than an information disclosure/access bypass issue.
@WebSinPat, can you elaborate on where any sensitive information is disclosed? Or, if you agree with my assessment, we can re-title the issue and begin working on the bug here (stale activity stream entires).
Comment #12
WebSinPat CreditAttribution: WebSinPat commentedThis is only because the message content is not configured to display that information. If comment-specific tokens are included in the message, then that data is displayed.
Not to mention that what brought this issue to my attention to begin with is that I blocked a user, and the activity stream is still reporting on comments the user made.
I'm not trying to argue that it's a bigger security issue though. I'll leave any sort of determination like that up to yall.
If the underlying bug is about staleness, then yes by all means let's work on freshness :)
(though the word stale implies temporariness to me, so I'll also just point out that the unpublished comment still remains in the stream 3 months later, so it's not an issue that times out or clears out of the cache.)
Comment #13
japerryOkay, so after re-hashing the issues in #8, #11, and #12 the bug exists but doesn't constitute a security issue.
Admins are able to expose messages that may contain sensitive data (titles, urls, etc) but requires manual customization of the tokens contained within messages. Since this isn't default commons configuration, its not really under the SA scope.
Nevertheless, this is a painful bug and should be addressed. I've started hacking at message and views, where some of them are working correctly (unpublished nodes), but comments definitely aren't following the parent permissions.
Comment #14
japerryThis is a two part patch.
First, we deny access to the comments itself. Any function rendering a message should get no output if the comment access is false, just like nodes.
Second, since we don't want a weird timestamp showing w/o its associated rendered message on commons_activity_streams, we perform a post_execute hook to preempt the message access per row. Instead of calling message_access per field (which allows the timestamp to remain and the message field to dissappear), we just do the same call as message_access does. Node access grants are already included in the view query.
This two step approach should fix the tokens and other oddities around rendering messages that users shouldn't be seeing.
Comment #16
japerryFixed in 3.13!