• Resolved lachlanphillips

    (@lachlanphillips)


    Hi, there is a critical bug in your plugin which I just found.

    in public function finalize_default_vary() it does a get_role().

    If the user is a superadmin, it will cache the page for that user’s superadmin data, but it will save it as guest data – this is because the role returns empty for superadmins.

    I think in public static function get_role() you need to add something like

    if (! $role) {
               if (is_super_admin()) {
                   $role = "super_admin";
               }
            }

    You also have a whole host of other issues like the _ls_cache_vary not being cleared if the user is only logged in for the session and just a host of issues that you guys should notice just using the plugin.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter lachlanphillips

    (@lachlanphillips)

    I’ll add that debugging this is very difficult because there’s

    1) no indication of the varys in the headers. Eg it’s impossible to tell whether it’s public or private, and which vary is being invoked (if at all)
    2) completely contradictory information in your documentation – any cookie with “_lscache_vary*******” is meant to trigger a vary, but in practice it appears that it needs to be setting both a clean “_lscache_vary” AND an additional vary cookie eg “_lscache_vary_mycustomvary”.

    Plugin Support qtwrk

    (@qtwrk)

    please correct me if I understand it wrong

    so this is what I tried

    set up a sub-dir network

    install and network activate LSCWP , enable network cache

    go to site 1 as super admin , visit frontend page as / checked HTML source output with timestamp

    create a new user as normal user , visit the same page , checked HTML source again

    they are showing different timestamp , which means they are not same page

    each one got its own private cache.

    • This reply was modified 2 years, 10 months ago by qtwrk.
    Thread Starter lachlanphillips

    (@lachlanphillips)

    The repro is:

    1) Create a new subdomain site
    2) Do not add the superadmin user to this site.

    The functions I mentioned check user role against the current subsite. Super Admins can be logged in WITHOUT being a user on the site, so it checks the user’s roles and finds none, therefore assumes the user to be a guest.

    Cheers

    Plugin Support qtwrk

    (@qtwrk)

    on debug log , I can see 
    
    with super admin to <code>/</code> , 
    
    

    05/04/22 16:55:17.697 [111.111.111.111:51499 3 y3x] Cookie _lscache_vary: admin_bar:1;logged-in:1;role:99
    05/04/22 16:55:17.697 [111.111.111.111:51499 3 y3x] X-LSCACHE: true
    05/04/22 16:55:17.775 [111.111.111.111:51499 3 y3x] [Ctrl] X Cache_control -> private ( logged in user )
    05/04/22 16:55:17.775 [111.111.111.111:51499 3 y3x] [Router] get_role: `

    then with normal user , I got

    05/04/22 16:57:10.551 [111.111.111.111:56787 3 pGv] Cookie _lscache_vary: admin_bar:1;logged-in:1
    05/04/22 16:57:10.551 [111.111.111.111:56787 3 pGv] X-LSCACHE: true
    05/04/22 16:57:10.566 [111.111.111.111:56787 3 pGv] [Ctrl] X Cache_control -> private ( logged in user )
    05/04/22 16:57:10.566 [111.111.111.111:56787 3 pGv] [Router] get_role: subscriber

    then with guest user, I got

    05/04/22 16:59:54.062 [111.111.111.111:57588 3 BOB] Accept Encoding: gzip, deflate, br
    05/04/22 16:59:54.062 [111.111.111.111:57588 3 BOB] X-LSCACHE: true
    05/04/22 16:59:54.117 [111.111.111.111:57588 3 BOB] [Router] get_role: 

    without cookie vary , but yes , it doesn’t give role assignment on super admin

    I think it’s more like small flaw instead of critical bug though , since the cache does not get messed up between super admin and guest user

    will advice our devs to check it further.`

    Thread Starter lachlanphillips

    (@lachlanphillips)

    Super_admin’s also aren’t considered for cache_varys in the admin page. You might need to look at this.

    Also in other caching plugins there’s a really clear header showing which vary is active. This would make debugging this kind of thing infinitely easier than trying to read through debug logs.

    Thanks

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Critical bug (multisite superadmin)’ is closed to new replies.