Can membership grouping and permissions only control the visibility of articles?

Can the membership group and permission only control the visibility range of articles? It can be controlled, but you need to understand what it controls: the visibility range is a rule that affects multiple outlets, not just blocking the detail page. The access permissions set by the user group and VIP group determine who can access which content, and there are at least four outlets, including the detail page, category list, in-site search, and interface reading. It only takes effect in one place, and restricted content will still leak out from other places.

The control point is not just the article detail page

The most commonly overlooked is the list and search. The detail page is blocked according to permissions, but the list page still displays the title, summary, and update time, which is equivalent to publicly exposing the existence of restricted content and part of the text. The more complete the summary is written, the more is lost.

Intranet search is the second point of leakage. Search results usually return entries according to keyword matching, and if the user group condition is not included during the indexing phase, non-members can see restricted titles as long as they find the keywords.

The interface read is the third leak point and also a bigger one. High-frequency capabilities such as document list and details, classification and tags are programmable in interface calls, where the front-end has intercepted and the back-end interface has not, making permissions just a decorative level of the page.

How to divide the group more stably

Divide the group according to the 'method of content acquisition', not according to 'how many people or few people'.

A way to divide readers into four groups: public visitors, registered users, paying members, and internal editors, with each group corresponding to a fixed content range. It should be noted that the number of groups is not the better the more: the groups are so detailed that each document can be matched with a group, in reality, no one can maintain them, and the probability of missing allocation increases.

A more stable approach is to let the grouping correspond to columns rather than single articles: restricted content is concentrated in a few controlled columns, and permissions follow the columns. Exceptions at the single article level are allocated separately, and small quantities can be maintained.

Which level of review should member submissions go through?

When open members submit articles, the permission control solves the problem of 'who can see' and does not solve 'what comes in'. This level relies on content security settings: sensitive word filtering is responsible for blocking or downgrading as soon as it is hit, keyword replacement handles expressions that can be released, and content review handles manual review.

The order of superposition of the three is based on cost: filtering and replacement run automatically when submitted, and only the part that has been downgraded and marked is reviewed manually. Otherwise, when the amount of submission increases, manual review will first put pressure on the site, rather than permission settings being wrong.

Permissions in drafts and recycling bins

Monitor the intermediate state of restricted content. The document status is divided into formal documents, drafts, pending release, and recycling bin. Drafts can be previewed through links with preview parameters. The spreadability of preview links is much stronger than that of formal release pages. If a link sent to a non-member can be opened, the permission is equivalent to bypassing.

Be clear about deletion: Deleting a formal document is to move it to the recycling bin rather than physically deleting it, and the content is still in the library. If the entries in the recycling bin are still retrieved by the list or interface, the content marked as 'off the shelf' is still visible to the outside world. When configuring permissions, include these types of statuses in the inspection scope.

How to verify consistency on the interface side

The core method is to take the same restricted document and call it once with different identities, rather than just looking at the backend configuration items.

First, call the interface document listed in the document list and detail capabilities with a public identity, to confirm that the restricted content does not appear in the returned results or in the abstract field. Second, log in with a restricted account and retrieve it again to confirm that it can be retrieved. Third, search for the same keyword that only matches restricted content within the site, and compare the number of results under the two identities.

Check if there is an existing interface with this title that is also worth verifying: being able to find it by title means that the title itself is exposed. The permission口径 of the API call side must be consistent with the front-end, and this step cannot be skipped.

Common questions

Just want to block the detail page, can't we ignore other places?

Not recommended. If there is no convergence in the list, search, or interface, the restricted content will leak out from there. The scope to be controlled is determined by the number of outlets, not by the page design.

If the grouping is set incorrectly, will it also block public content?

Will. When permissions are received by column, publicly accessible content mistakenly attached to restricted columns will also be blocked. After the change, it is a cost-effective verification method to go through the list and search using a non-member identity.

Should member submissions be reviewed before being published?

It depends on the content risk. Columns involving contact information, external links, and industry qualification descriptions are recommended to be reviewed before publication, while others can be published first and reviewed later, but sensitive word filtering and keyword replacement should take effect immediately upon submission.