Project

General

Profile

Bug #11453

403 error on Firefox

Added by Marilyn Weber 5 months ago. Updated 5 months ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
WordPress (misc)
Target version:
Start date:
2019-05-14
Due date:
% Done:

0%

Estimated time:

Description

I'm unable to log into my site when using Firefox - a 403 error pops up. I can get in though the https://commons.gc.cuny.edu/ page, and I can get in using other browsers, but thought you should know.


Related issues

Related to CUNY Academic Commons - Bug #11506: Home Page Slideshow - blank slideResolved2019-05-31

History

#1 Updated by Boone Gorges 5 months ago

  • Status changed from New to Reporter Feedback

Could you please give some more info about what you mean by "I'm unable to log into my site"? What's the URL of the site you're visiting, what are you clicking on, etc?

The 403 is because of some spam-preventing cookie detection; you should not be seeing 403s if you are first visiting a regular Commons page. It could be that your cookie settings in Firefox are not allowing certain kinds of cookies, but it's hard to know without more info about exactly which actions you're performing.

#2 Updated by Marilyn Weber 5 months ago

https://historyprogram.commons.gc.cuny.edu/

Click on Login in the upper right. It's prepopulated with my name and password. This is the same way I've logged into the Commons on this (relatively new) computer for weeks. I didn't change anything at all from when it worked yesterday, but perhaps the GC did?

#3 Updated by Boone Gorges 5 months ago

  • Assignee set to Raymond Hoh

Got it - thanks, Marilyn. Does your workstation remember logins and other stuff like that when you log off in the evenings? I'm wondering whether the GC clears all cookies when the user's session ends.

In any case, a normal page visit - like when you load historyprogram.commons - sets the security cookie. I've just confirmed that it's working. However, it loads at the very end of the pageload, and I see that a couple assets on historyprogram.commons are causing this pageload to be incomplete for about 15 seconds on a completely empty browser cache. So, if you load the page with a totally empty cache and no cookies, and attempt to log in before the page is completely loaded, then the cookie will not be set, and you'll see the 403. For your purposes, you can just let the page load all the way, and the problem should go away :)

Ray, I wonder whether there may be a way to mitigate this issue, potentially by loading the cookies-for-logins cfc.php file earlier in the document body. Do you think this would cause problems and/or is worth the effort?

#4 Updated by Marilyn Weber 5 months ago

It does remember logins, etc. I'm sure your theory that I'm attempting to log in before the page is completely loaded is correct - I'm not known for my patience!

NBD at all, just thought you might want to know.

#5 Updated by Raymond Hoh 5 months ago

  • Category name set to WordPress (misc)
  • Status changed from Reporter Feedback to Assigned
  • Target version set to 1.15.2

Ray, I wonder whether there may be a way to mitigate this issue, potentially by loading the cookies-for-logins cfc.php file earlier in the document body. Do you think this would cause problems and/or is worth the effort?

Yes, there is a new hook in wp-login.php as of WP 4.6 that we can use -- 'login_header'. Should be as simple as switching to this hook, but I'll do some local testing.

#6 Updated by Boone Gorges 5 months ago

Thanks!

#7 Updated by Raymond Hoh 5 months ago

  • Status changed from Assigned to Staged for Production Release

Boone, ignore my previous comment. I thought you were referring to the wp-login.php page, but instead you meant any frontend page.

The Cookies for Comments plugin uses the 'wp_footer' hook to inject their image file because it is reliable and used by most themes. To move the image further up the DOM, it's possible to hook into 'loop_start' or 'loop_no_results' due to the usage of have_posts(), which is used in most theme template files.

In commit 98cc800, I've done just that. If the theme template does not utilize have_posts(), we fallback to injecting the image into the 'wp_footer' hook as always.

#8 Updated by Boone Gorges 5 months ago

Awesome!

#9 Updated by Boone Gorges 5 months ago

  • Status changed from Staged for Production Release to Resolved

#10 Updated by Boone Gorges 5 months ago

  • Related to Bug #11506: Home Page Slideshow - blank slide added

Also available in: Atom PDF