Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Under certain circumstances, Views 3 seems not to honor access permissions as configured in "basic settings". The attached View has three displays (Default and two Page displays), and none should allow access for anonymous users. However, if an anon enters the defined path, het gets a page listing.
This is extremely strange since I cloned this view a couple of times, and with a slightly different configuration I get the expected "Please log in" screen for anons, when the URL path is accessd directly.
Both Views use relationships on different Flags, one display uses an argument, and one uses an additional reltionship on a 'Flag Note' (an contributed add-on module for Flags). Please adjust the issue queue accordingly if contributed modules have the potential to circumvent Views access permissions.
At ./admin/user/permissions, the "Access al Views" permission is unchecked for user role "Anonymous".
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | lieblingsfilme-not-visible-for-anons.txt | 46.56 KB | asb |
Comments
Comment #1
asb CreditAttribution: asb commentedThis one works imho properly in regard to Views' access permissions.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commented1) Can you be 100% sure that the page you're seeing is the view in question?
2) Do the access properties of any of the pages appear overridden? There could be an error here where it thinks there is in fact no access control on the page.
Comment #3
asb CreditAttribution: asb commentedAd 1) 100% is a bit much, but I'd say: reasonably sure. The page has text in it that should exist only in the View (empty result text), and the page's code includes tags like
Ad 2) Not sure if I understand the question correct; in the Views UI, overridden values are displayed in italics; based on that, both page displays have overridden values (grant access for "multiple roles", but anonymous is always unchecked).
At least in my use case this is not a security issue (I think), because anons can not flag anything, and the View can filter to flagged content; what puzzles me is (a) that I get a page where I wouldn't expect one (because of the Views access permissions, and because there is no Views caching), and (b) the different behaviour of two very similar Views. Hmm...
... found it, it is not a Views issue. What I got was a page delivered through the static page cache ('Boost'), so it wasn't refreshed by "Clear all caches" in admin_menu or drush. After a "Clear Boost's Database & File Cache", anons get the correct page ("Please log in..."); this also explains why the other View was behaving differently, it was not in Boost's static page cache.
However, this isn't the behaviour Boost should deliver, I think, especially because both Views are configured for no caching (in Views). Also, the Views in question are not listed under "Views to run when looking for content relationships" at
./admin/settings/performance/boost, which is also strange.Adjusting issue queue and trying to figure out how the empty result page got into Boost static page cache...