Wordpress: Cookies are blocked or not supported


When entering the control panel, an error is displayed: Cookies are either blocked or not supported by your browser. To use WordPress, you need to enable cookies. In Wordpress FAQ among the list of most common causes of this error are: “Caching rules when using the Cloudflare service. It is necessary to disable caching for the wp-login.php file”. We did exactly that, but the error still occurs.

For security reasons we use “All In One WP Security &Firewall” plugin to hide login page, but redirect page also with prefix “wp-”. In addition, the Captcha is also not updated immediately.

Try to exclude the file only


wp-admin can be ignored?

Try this first. This is also a security thing.

The error seems to have ceased, but what about other pages? Сaptcha still doesn’t work, it constantly shows the cached question.

There’s no slash after wp-login.php
So that first page rule won’t bypass cache for Login.

This is how I do it. Mind you…don’t go browsing your site while logged in, as Cloudflare will cache all those “Edit” links you see on posts and pages. Maybe some other stuff you don’t want showing up in the cache.

So if i make page rule with wp-* and no slash, it ican work with all pages with the prefix “wp-”?

Yes, but then you wouldn’t be caching anything from wp-content, like uploads (images).

if the rule with wp-content place in the first place?

That would work. I’m not sure why I didn’t do that, but I thought I had a reason. Ah…I wanted to cache wp-includes. But it’s up to you.

At the moment everything is working fine and captcha too.

1 Like

As there are a limited number of page rules included in each plan, only 3 for the free plan, one always has to make a compromise between what we want and the limit we have, and set priorities.

If you don’t mind buying more page rules, this article lists several that may help a Wordpress website.

As for the wp-login.php page, are you sure you need to bypass cache? I don’t think so. I don’t think CF caches wp-login,php, even when under Cache Everything page rule. You might want to check whether your page caching plugin isn’t caching the wp-login.php page. I use WP Super Cache, and it has a list of exceptions you can add to avoid caching certain pages. And if you only want to add protection to the login page, there are other options.

If you are the only person using the admin area, you can have your wp-login.php page and your /wp-admin/ area protected by Access Policies. You can have up to 5 users accessing Access Policy-protected areas of your websites for free.

If your website has many users, you can set the protection for wp-login.php using a Firewall Rule:

(http.request.uri.path eq “wp-login.php”) then: JS Challenge (afaik, this is equivalent to the “I’m under attack” setting elsewhere)

You could then merge both rules that are setting “Cache Level: Cache Everything” into one, freeing up one PR to be used with /wp-json/. This one is needed, afaik, because Cloudflare will cache /wp-json/ and make plugins that depend on it to stop working properly (such as the Redirection and Simple History plugins)

For the price of 5 extra rules, you can set up Workers and use Pat Meenan’s setup:

As for putting Access in front of wp-admin, that would block admin-ajax, which often needs to be accessible.

Hey @sdayman, thanks for the tip on Workers.

As for Ajax, I had this fear myself, but after using Access for a few months already, I’ve had no problems with it. As I understand it, Access will only authenticate external hits, not hits that comes from you origin server, so as long as plugins and themes are well coded, this shouldn’t be an issue.

1 Like

with wp-* rule you dont need rules for wp-login, wp-admin or wp-json. How Access Policies works with dynamic ip?

Right! If both wp-login, wp-admin and wp-json need the same set of security and performance rules, you should be fine. I actually just adjusted my wp-admin page rule to include Disable Security and turn off Browser Integrity Check, as in my case /wp-admin/ is already protected under Access.

In my case I opted for using a ID provider (Gmail and Github). What happens is, I am stopped on my first visit (and every time authentication expires) and asked my email. The email is then first authenticated by Google (if you are no logged in, you have to at this point) and subsequently should be authenticated by Access, provided the email address is on a pre-defined list. This avoids the issue of dynamic IP altogether.