fix accessibility of silenced user posts

[colin-axner]

Change view post collection queries to verify that the authenticated user viewing a silenced collection is either the owner or admin. Previous behaviour was only checking if the post owner was also the collection owner which always returned true, causing the if statement to be skipped.

closes: #374

---

• I have signed the CLA

[mrvdb]

I've applied this patch for qua.name. Works for me with one exception, which may be a local issue, I haven't dived in yet.

Posts from silenced users are still visible in the 'reader' ( URI '/read' ) After restarting writefreely they are not visible anymore. I think posts from silenced users should also be removed from the 'reader' page without having to restart writefreely (possibly a caching issue?)

[thebaer]

I agree, we should make it so silenced users are immediately removed from the Reader, too. This does sound like a caching issue -- maybe we could invalidate the cache anytime the Reader is enabled and a new user is silenced? Probably around here:

https://github.com/writeas/writefreely/blob/f534ee1deccbe5d161349554efa9aa0a2aac55df/read.go#L159-L161

[colin-axner]

Sounds good. Would it be safe to set tl.posts = nil before calling updateTimelineCache to force the cache to be reset or alternatively pass in a boolean indicating a cache override?

[thebaer]

I think the best way would be to pass a boolean that invalidates the cache. Since this is an expensive query, we prefer to keep tl.posts permanently populated after it first loads -- even if it serves stale content to a visitor or two, it keeps the Reader section responsive.

[colin-axner]

maybe I am missing something, but wouldn't Memo.Invalidate need to be modified to support this functionality.

The cache is an unexported field so in order to forcibly reset the cache, Invalidate needs to take in a boolean to bypass the last duration.

Should I instead add a third function Reset to forcibly reset the cache without breaking API?

[thebaer]

Should I instead add a third function Reset to forcibly reset the cache without breaking API?

Yes, I think that'd be the best route to go.

[colin-axner]

made the changes based on the linked pr. I'm not sure if I reset the cache in the right place after silencing the user? It is unclear to me if there's a different handler called when an admin clicks "silence" on a user.

Still need to manually test either via modifying the go.mod locally or merging the web-core pr and updating the commit. Leaving as a draft until the web-core pr is merged

[thebaer]

Moving this out of draft, now that writeas/web-core#11 is merged.

[colin-axner]

updated the web-core commit. Will try to test this week

[colin-axner]

I have tested these changes and they work as expected. When the user is silenced, the posts are not viewable directly or on the reader. When the user is unsilenced, the posts will be added back to the reader once the cache is refreshed

The UI is looking better. Looking forward to the next release

[thebaer]

Yep, tested and this works great! Thanks!