Project

General

Profile

Actions

Bug #2811

closed

wp-login.php cookie restriction sometimes fails

Added by Boone Gorges over 10 years ago. Updated about 10 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
WordPress (misc)
Target version:
Start date:
2013-10-02
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Hi Ray - I enabled the Cookies for Login plugin, and it seems to be working in my tests, but we've had at least one report the .htacc blocked what should've been a legitimate login. I was hoping we could use this space to talk over the possible points of failure.

From my understanding, the setup works like this. On 'init', the cookies-for-comments plugin creates a dynamically generated img file, whose sole purpose is to set a cookie with a certain key. The .htaccess rule then rejects any POST requests to wp-login.php that are not accompanied by the specified cookie header. (Actually, if using the .htaccess rule, it looks like your cookies-for-login plugin doesn't really do anything - is that right?) So, if someone is getting bounced against the .htaccess rule, there are a few possible culprits:

- The cookie is not being set, because the fake image is not being loaded. It looks like it's supposed to load at wp_footer, and it's possible that on some pages of the Commons (keeping in mind that we allow many themes, people can log in on their own blogs, etc) wp_footer is not being run
- The cookie is not being set, because cfc_set_comment_style_cookie() is not running. It seems to me that 'init' should always fire, but maybe I'm wrong about that? The plugin is network-activated.
- The cookie is being set, but with incorrect/inconsistent key. That is, it's supposed to be keyed using the cfc_key option, which I've then hardcoded into the .htaccess check. It looks to me like they match properly, but maybe this has gone awry somewhere?

For the moment, I'm going to disable the .htaccess restriction for wp-login.php on the live site.

Any thoughts you have about how to debug would be most welcome!

Actions #1

Updated by Raymond Hoh over 10 years ago

(Actually, if using the .htaccess rule, it looks like your cookies-for-login plugin doesn't really do anything - is that right?)

That's not quite correct. Donncha's plugin does not attempt to load the the specialized image on the login page. My plugin adds the necessary code to load up the image on 'login_init'.

However, since CUNY uses a stylized version of wp-login.php, it appears that this image is loading twice. Once on the 'login_footer' hook and again on 'wp_footer'. I don't think this will cause any conflicts, but thought I'd mention this.

- The cookie is not being set, because the fake image is not being loaded.

This is the most likely culprit. This can occur if the user is blocking images with some form of plugin or if the user has disabled cookies from loading.

In Donncha's FAQ, he states that minifying plugins can interfere with the loading of the image and cookie. Not sure if this is the case with us.

Actions #2

Updated by Boone Gorges over 10 years ago

Thanks for the thoughts, Ray.

My plugin adds the necessary code to load up the image on 'login_init'.

Ah, good call.

This can occur if the user is blocking images with some form of plugin or if the user has disabled cookies from loading.

Hm. I don't think we need to worry too much about users who have disabled cookies, because they're not going to be able to log into the Commons in any case (and I get the impression that the user who reported the issue didn't have a problem using the site in the past, which suggests that it's not a cookie restriction in itself). The image blocking thing is interesting - do you have any idea what kind of browser plugin would do this? Maybe some security thing? Do you think it would make any difference if we used the CSS-based cookie-setter rather than the IMG-based one?

This stuff is hard to guess about when we can't reproduce the issue :)

Actions #3

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.5 to 1.5.6
Actions #4

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.6 to 1.5.7
Actions #5

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.7 to 1.5.8
Actions #6

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.8 to 1.5.9
Actions #7

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.9 to 1.5.10
Actions #8

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.10 to 1.5.11
Actions #9

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.11 to 1.5.12
Actions #10

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.12 to 1.5.13
Actions #11

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.13 to 1.5.14
Actions #12

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.14 to 1.5.15
Actions #13

Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.5.15 to 1.5.16
Actions #14

Updated by Boone Gorges about 10 years ago

  • Target version changed from 1.5.16 to 1.5.17
Actions #15

Updated by Boone Gorges about 10 years ago

  • Category name set to WordPress (misc)
  • Status changed from Assigned to Resolved

The protection has been disabled on the site for a long time now, and we haven't had any issues with bot traffic or other attacks. I'm going to permanently remove it and close this ticket. If problems arise in the future, let's return to this discussion.

https://github.com/castiron/cac/commit/e65abc5b9ae32997c9d1737e823fc1583e0a1bc8

Actions

Also available in: Atom PDF