Repository navigation
Gate browsing and searching on a view access level (supersedes #1896) - #1938
Merged
Merged
Conversation
…nt boolean Rework of the three previous commits, which added an "allow public search" radio to publications, resources and tags and bounced guests to log in from one entry point each. The intent, keeping bots off the expensive listing queries, is kept; the mechanism changes: - Each component gets a browse_access (tags: search_access) config field of type accesslevel, default Public, so nothing changes on hubs that leave it alone. "Registered only" is one choice among the hub's view levels rather than a special case. - SiteController gains canView($level) and requireViewLevel($level, $message). A guest without the level is sent to log in with a return URL; a logged-in user without it gets a 403. The three copies of the redirect block go away, as does the 410 Gone that publications threw for a guest tag-filtered browse, which told crawlers a valid URL was permanently gone. - The level is enforced on every listing and search path, not one per component: publications browse; resources browse, the tag browser (on by default, so the browse fallback never ran) and the AJAX browser; the tags view and its feed, counting the de-duplicated tags rather than the raw list so "/tags/foo," is not a multi-tag search; the resources API list when a search term is given; and the publications and resources search plugins. ViewLevelGateTest covers the pass, guest-redirect and logged-in-403 paths of the helper.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #1896, carrying its three non-merge commits and adding one rework commit, as proposed in the review there.
What changes relative to #1896
browse_access(tags:search_access) config field of typeaccesslevel, default Public. The hub's existing view levels (Public, Registered, Special, and any a hub defines) are the vocabulary, as they already are for com_projects' default access.Hubzero\Component\SiteController,requireViewLevel($level, $message), replaces the three copied redirect blocks: a guest without the level is sent to log in with a return URL, a logged-in user without it gets a 403. The 410 Gone for a guest tag-filtered publications browse is gone./tags/foo,is not a multi-tag search; the resources APIlistwhensearchis given; and the publications and resources site-search plugins.Verified
ViewLevelGateTest(new) covers the pass, guest-redirect and logged-in-403 paths; lint clean, config XML well-formed, no leftover references to the old option./publications/browse,/resources,/resources/tools,/tags/a,b,/tags/a,b/feed,/search?terms=…and/api/resources/list?search=…all behave as before with no PHP diagnostics. (/publications/browse?tag=…returns 403 here with or without this change; that is an Apache rule on this hub, not PHP.)Note for hubs that enabled #1896's option on a dev branch: the old
allow_public_search=0has no effect any more; set the component's browse access to Registered to get the same behaviour.🤖 Generated with Claude Code