Next

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

Thanks for highlighting this @medworthy. Moved into this sprint; may be delayed to next sprint depending how I get through my existing jobs.

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

@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

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.

https://gitlab.com/minds/engine/blob/e2f62b2e3845b29123b5c280bd2a2c2edc3357f0/Core/Blogs/Blog.php

In _extendExport, $this->_eventsDispatcher->trigger('export:extender', 'blog', [ 'entity' => $this ], []) is never reached, as _extendExport is never called, so the subsequent export:extender does not trigger, which should be stripping out the body from the blog.

If I change the function signature of _extendExport($export) to export() The body data is stripped, still doesn't load though. I can't find any calls to _extendExport($export). So to me, this implies some part of the system is expecting export() to be in the blog function.

added 3h of time spent at 2019-10-09

added Status::Follow Up scoped label and automatically removed Status::InProgress label

added Status::InProgress scoped label and automatically removed Status::Follow Up label

$this->_eventsDispatcher->trigger('export:extender', 'blog', \[ 'entity' => $this \], \[\]) Infact is reached, and isn't read upon being registered.

added Status::Review scoped label and automatically removed Status::InProgress label

Overspent time on this, had gotten to a few solutions, but they were all quite hacky workarounds. Seems to be something weird going on when the event is not registered. I think this one maybe could still be considered a workaround, but isn't so hacky as I think the blog namespace is a valid place to store blog paywall logic.

Still there is an underlying issue in that the old code was not registering.

added 3h 30m of time spent at 2019-10-10

mentioned in issue #2080 (closed)

When this bug is resolved @javanick Should follow up with minds::@cellblock07208 and minds::@medworthy to thank them and tell them it's fixed.

engine!359 (diffs)