Support » Plugin: WPS Hide Login » WP core post protected message hardcodes wp-login.php

  • Resolved fractaleater

    (@fractaleater)


    Have used this for a while. Has evolved quite a bit. Great work!

    So after the latest PHP\WP\theme\plugins update round, I found that visitors attempting to access password protected posts were reaching 404 after valid authorization.

    Checked into site’s language en_GB.po translation file for “content is password protected.” and found reference to wp-includes/post-template.php::get_the_password_form. In there, you can see that the form action is hard coded to:

    ` .. site_url( ‘wp-login.php?action=postpass’, ‘login_post’ ) ..

    get_the_password_form applies a filter ‘the_password_form’, so the hard coded url could be changed. I notice the plugin README references this function, but I can’t grep any code references.

    Before defining a filter, is there already some code to deal with this in Hide Login that might be malfunctioning, or is this something WPS would like to do for next release?

    Thanks for the effort and that invaluable resource: time.

    Richard

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

    (@fractaleater)

    Just a follow up here. So, the problem is located in the plugins_loaded and wp_loaded hooks.

    The password submit action generated by get_the_password_form sends “wp-login.php?action=postpass”, and post data of the actual password. In plugins_loaded, the plugin sees the request as a wp-login.php anonymous access attempt and quashes it by stomping on the request URI. Later, wp_loaded checks $_GET and $_POST, which it rightly expects to have been filled earlier, to identify “action=postpass”, but at that point, both $_GET and $_POST appear to be empty (at least using error_log). This causes the plugin to pass the request along as is, and the browser gets a 404 response.

    The problem is that in wp_loaded hook $_GET and $_POST are both empty.

    Similarly, both are empty in the earlier plugins_loaded hook. I suppose one could make the thin argument that changes to $_SERVER[‘REQUEST_URI’] in plugins_loaded trigger changes to $_GET and $_POST, and my error_log statements that occur before the modification could be a result of output buffering, but I disabled the modifications in plugins_loaded and $_GET/POST were still empty. I also changed the priority the hook tomuch earlier and much later to bypass any naughty plugins without effect.

    So, unclear why these PHP globals are empty. The site has PHP 7.4.15. WordPress W3 Caching disabled, CloudFlare CDN in development mode, tried Chrome browser incognito and normal window, and logged in admin user, all result in empty $_GET/POST. Used Chrome development tools to verify form and expected URL.

    Best guess with existing information is htaccess QSA flag behavior needs to be implemented/checked in WordPress add_rewrite_rule, but less clear what is going on with empty $_POST when it should contain “post_password”.

    Richard

    Thread Starter fractaleater

    (@fractaleater)

    Just realized that I misread a critical line in wp_loaded that completely invalidates wp_loaded as the source of the problem. wp_loaded is designed to ignore action=postpass. Although probably $_GET/POST should still be populated.

    More peculiar is that the first test run (10 hours after last run), displayed the protected content. A confirmation run (30 seconds later) failed. Now seems more like a caching issue.

    Thread Starter fractaleater

    (@fractaleater)

    Ok, definitely a caching problem.

    Both plugins_loaded and wp_loaded now have expected values in $_GET/POST.

    Site uses Cloudflare. Instead of enabling development mode to bypass cache, disabled cache for the domain, and password protected page now loads protected content. Verification completed and successful for logged in users/normal users/incognito.

    Thread Starter fractaleater

    (@fractaleater)

    Enabled Cloudflare CDN for the domains, but disabled “Railgun” dynamic content accelerator. Plugin works properly. Verification completed and successful for logged in users/normal users/incognito.

    Thread Starter fractaleater

    (@fractaleater)

    Notification made to Cloudflare.

    As a final attempt to enable Railgun, added “Cache-Control: no-store” for all pages in wp_header filter, but that was ineffective. It might be possible to control Railgun with special headers, but I found only “no-store”, which continued to result in 404 responses.

    Ultimately, denial of authenticated access to password protected forms while using WPS Hide Login is related to cached 302 redirects for wp-login.php based forms by the Cloudflare Railgun product.

    Richard

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.