Accessibility to locked blog articles
Summary
With reference to a recent H&S enquiry, I have tested an example blog article and found that whilst not purchasing access to locked articles, I am able to copy and paste the obscured text content of said locked article into external text editors and word processor applications.
The example blog article also contains video content (provided via the YouTube bridge) in which the audio content can be listened to whilst the article is locked.
Steps to reproduce
View a blog article whilst it is locked (ie. needing a predetermined amount of tokens to be able to access said content) and then attempt to listening to any video / audio content, as well as attempting to copy the text content to an external application.
Platform information
I believe that this is user platform neutral. However, I have tested this whilst using Firefox (x86_64 version 68.0.2) and Chromium (x86_64 version 76.0.3809).
What is the current bug behavior?
See above
What is the expected correct behavior?
Locked content should not be accessible to the user (until the user purchases access to said content).
Relevant logs and/or screenshots
Reference:
-
Original Help And Support Enquiry
https://www.minds.com/newsfeed/1020105341986635776 -
Example Blog Article
https://www.minds.com/cellblock07208/blog/from-the-pulpit-my-beginnings-with-religion-1019970882463047680
changed the description 3 times within 10 minutes
changed the description
changed title from Accessability to locked blog articles to Accessibility to locked blog articles
changed the description
assigned to @benhayward.ben
added Priority::1 - High Product::Blogs Type::Bug scoped labels
added Sprint::09/11 - Nuanced Numbat scoped label
- Developer
Thanks for highlighting this @medworthy. Moved into this sprint; may be delayed to next sprint depending how I get through my existing jobs.
Edited by Ben Hayward added Sprint::09/25 - Oldfashioned Owl scoped label and automatically removed Sprint::09/11 - Nuanced Numbat label
changed time estimate to 5h
added Status::InProgress scoped label
mentioned in commit 26eb97c2
mentioned in merge request !573 (closed)
added 2h 30m of time spent at 2019-09-25
added Status::Review scoped label and automatically removed Status::InProgress label
changed weight to 1
assigned to @edgebal
added Squad::Yellow scoped label
- Owner
@benhayward.ben what is the status of this task?
unassigned @edgebal
added Sprint::10/09 - Pink Panther Status::Backlog scoped labels and automatically removed Sprint::09/25 - Oldfashioned Owl Status::Review labels
added Status::InProgress scoped label and automatically removed Status::Backlog label
- Developer
My investigation revealed to me like the ACL is not firing correctly. I suspect https://gitlab.com/minds/engine/blob/abacfb66bb1bcbc616c81761835ada048c7723ac/Core/Wire/Paywall/Events.php to be at fault, this was assigned over to Emi at his request but happy to take a further look.