Logged in users not shown as logged in [LiteSpeed Cache/CDN Issue (Hostinger)]

Hi,

I would like to report, again, after YEARS (with this account and others that I have), that users that log in, still appear as logged out after login. This is an ongoing issue that goes back to at least the end of 2023. Many many users have reported it, and never ever has there been a proper solution, only solutions that work for some users.

The only thing that effectively works is deactivating the Litespeed plugin completely. I have tried ALL other methods, ALL millions of SETTINGS, I have prayed to ALL possible gods. NOTHING works. Yes, Cache logged-in users is deactivated. Yes, I also tried the PHP snippet Code snippet to disable caching for logged in users , which does nothing. Hostinger A.I. did not come up with a solution either. Things work temporarily, and then not anymore.

I understand that this is a Litespeed issue, but even Hivepress has docs referring to how to configure Litespeed for best results, so they should be able to work together. I am absolutely terrified with each Litespeed or Hivepress update, because old solved problems tend to return, again and again. I do not understand how other users can maintain their websites with Hivepress running, if this constantly pops up again. Other plugins are not an issue.

Please, please, please please……users using Hivepress with Bookings and Marketplace and Litespeed, and hosted on Hostinger, let me know what the trick is to make this work once and for all.

And dear Hivepress devs, I am not a premium user anymore, but this issue dates back to forever…and it seems to happen only when combining Hivepress and Litespeed (and possibly Hostinger), because otherwise half the world would have had troubles. There might be something in the code for the login flow that is just not working when using Litespeed. Please try to fix this.

If no one has a solution, does deactivating Litespeed (at website level) really cause a big drop in performance (when hosted on Hostinger)? I am thinking of quitting, really. I can’t be every week spending hours to solve this without ever having a solution.

Thank you

A very desperate user

Hi,

Thanks for the details, and sorry if you had trouble setting up LiteSpeed Cache with HivePress. We officially recommend using this cache plugin, so we’re interested in resolving any conflicts with LiteSpeed Cache settings.

Please let me know if you can reproduce the same issue on the theme demo https://listinghive.hivepress.io/ We have LiteSpeed enabled on all of the theme demos, and if the issue doesn’t occur there, this may be somethig related to LiteSpeed settings, or how LiteSpeed conflicts with the hosting-side cache (most hosting providers nowadays have their own server-side caching solutions).

Hi,

no, on your demo site it works well. It seems to affect a very specific configuration. In my case, Wordpress+Woocommerce+Hivepress+Litespeed, hosted on Hostinger (business plan with CDN and server side integration with Litespeed).

After another 12 hours of multiple tries, I think the main issue lies with the (Hostinger/Litespeed) CDN. After logging in, if the page you are on was cached by the CDN, it will serve you that cached page, no matter what. After login, all wordpress login cookies are created, together with the *_lscache_*vary cookie, which Litespeed uses to check user online status. But even with those cookies present, and after reloading the pages multiple times, you get served the cached page that you saw before logging in. The CDN cached version always bypasses all new tries of modifying the (Litespeed) cache control headers or other ideas.

If you visit a page for the first time and it was not yet cached by the CDN server, it caches it locally, but you can login normally. It is definitely only the CDN creating problems.

My suggested solution (as a non-developer simple idea), that would be applicable for any other caching plugin with CDN, would be that Hivepress, after login, would force a new request to the same page you are on, to get “some data”, could even be some tiny .jpg or whatever. This might be fake data just to trigger a real request to the original server database. In any case, after login, it has to force somehow to get a “new” page. The other solution is that Litespeed themselves finally figure it out, but they blamed Hivepress for the malfunction here Litespeed Cache conflict with login - #4 by unitehearts.in , but their solution does not work either. Their cookie is correctly created, but I don’t know about the POST issue. I assume after login there is no AJAX reload, that would be strange, but that would be a problem too I guess (just beginners wonderings).

For further info, here are some of the many things I tried and failed the last 12 hours:

  • Modify the headers with PHP sending new headers for cache control. I tried simple snippets and also Wordpress action and filter hooks (send_headers….wp_headers…)
  • Trying to execute PHP snippets depending on the existence of Wordpress or Litespeed login cookies
  • Trying to set cookie varys
  • Retrying Litespeed basic settings like Object cache and Browser cache ON/OFF etc
  • Execute code depending on user role or logged in status
  • Using Litespeed’s own action hooks to modify cache control directives
  • Using Litespeed’s own action hooks to purge caches
  • Using the Hivepress add_action( ‘hivepress/v1/models/user/login’) hook to try and execute code to modify cache settings or headers
  • etc etc

Nothing of the above works because after login it simply does not execute any code because we receive the logged out version cached page (it is strange however that it does create all the login cookies). This is also why no other solution proposed by other users will work either.

The only thing that works partially is to force the private cache only. Here is the PHP snippet:

do_action( 'litespeed_control_set_private', 'to avoid serving cached pages to logged in users' );   

This works so far, but of course skips the CDN caching, which might affect the performance of websites with a lot of traffic.

Hope this helps!

Thanks for all the details, really appreciate this. Please let me know if you tried to contact Hostinger support, maybe they suggest some PHP/JS snippet to flush their CDN cache after the login cookie is set? We may add this to future HivePress updates, for example if the second redirect after the login or requesting any website resource refreshes hosting-side cache.

If there’s also an option to disable their CDN cache, I’d recommend this because LiteSpeed already caches pages and serves them as static HTML, if you also enable their image optimization then another layer of cache added by the hosting provider is not needed.

I have now been in contact with them. In short:

  • No, there is no possible snippet to flush the CDN cache
  • They confirmed “Hostinger CDN currently doesn’t support cookie-based cache bypass, so logged-in users may see cached (logged-out) content”

The only solutions are:

  • Disabling CDN completely
  • Setting CDN in Development mode: “CDN stays in front (Anycast edge, TLS termination, WAF options, image optimization/minification if enabled), but it doesn’t cache—it forwards to origin each time.

I am testing the develpment mode. I imagine it will work. Hopefully in the future they add cookie based CDN bypass for logged in users.

Not sure if adding some code to Hivepress “requesting any website resource” will refresh hosting-side cache after login, but it is the only temporary fix that might work until they update themselves.

Hope this helps

Thanks for the extra details, in this case I recommend temporarily disabling their CDN as serving static HTML pages via LiteSpeed + image/JS/CSS optimization + object cache may be enough for a good PageSpeed score and user experience.

I assume the issue occurs because we implement logging in via REST API (instead of legacy WP AJAX API), so the login cookie is set via REST API, but the cached website front-end is not “aware” of this. LiteSpeed seems to detect this without issues, but various hosting-side caching solutions may not.