New to the community? Start here

WPMUDEV Dashboard hijacking other requests

I check my WPMS sites several times each day to address spam signups. I hit the homepage, then click a link in my toolbar to “/wp-admin/network/users.php?sortby=registered&order=desc&apage=1&orderby=id” – which works VERY well to see the most recent signups. This process has worked perfectly since the WP 3.x release.

But now it doesn’t.

Today I went thru the same process I’ve been doing for several years on two sites and the requests on BOTH were hijacked by the WPMU DEV Dashboard plugin and redirected to “/wp-admin/network/admin.php?page=wpmudev” The data was “null” again, too (exactly as it was the last couple days before changing the http/https thing).

Yesterday when it was first hijacked I thought it might be a fluke – maybe I clicked something and didn’t realize it. Nope.

This needs to be fixed. While I could (I assume) minimize access to the dashboard to prevent the account I use all the time from being hijacked like this, wouldn’t it just be better to not hijack my requests when I’m in the middle of something else?

Mon, 28 May 2012 19:06:53
More WPMU DEV Dashboard discussions
WPMU DEV Dashboard
  • Aaron
    • Ex Staff

    I’m not able to recreate this at all, even tried sorting by other user fields and searches.

    Are you using 3.1.1?

    There is a function in the plugin to redirect to that page only one time after you activate for the first time on a site. But if you have an api key set, or have ever been redirected it will never happen again.

    If still happening, try commenting out this line at the top of the main plugin file:

    //add_action( 'admin_init', array( &$this, 'first_redirect' ) );

    If that stops it, then we can at least narrow it down to that and figure out what’s going on.

  • Shawn
    • The Crimson Coder

    Yes, I’m using 3.1.1.

    I figured I’d better not change anything until I could replicate it. Tonight it happened again. That’s three times on two sites. Here’s the log entries from one of them, showing it is in fact a 302 redirect to the wpmudev plugin:

    [25/May/2012:21:57:01 -0500] "GET /wp-admin/network/users.php?sortby=registered&order=desc&apage=1&orderby=id HTTP/1.1" 302 ...
    
[25/May/2012:21:57:02 -0500] "GET /wp-admin/network/admin.php?page=wpmudev HTTP/1.1" 200 ...

    I’m commenting out line 74, as suggested. I’ll let you know tomorrow if that helped.

  • Shawn
    • The Crimson Coder

    It’s now been 18 hours since I commented out line 74 in update-notifications.php

    I haven’t experienced another bounce/hijack since. I was getting them about every 12 hours or so, so I think this is resolved.

    I now respectfully request that this be the default behavior in future releases. Instead of hijacking the URL, how about you just alert us with an infobar at the top or something?

  • Aaron
    • Ex Staff

    Your the only one that’s reported this problem, it has to be something unique or wierd with your server/setup.

    Here is the code, you can see everything that must be true for it to redirect:

    $redirected = get_site_option('wdp_un_redirected');
    
if ( is_admin() && !defined('DOING_AJAX') && current_user_can('install_plugins') && !$this->get_apikey() && !$redirected && !(isset($_GET['page']) && $_GET['page'] == 'wpmudev') ) {

    – Only the admin/super admin

    – API key has to not be saved

    – has to have never redirected before

    Which means somehow on your server site_options were returning as null for certain admin queries, not a normal or good thing, and possible a symptom of other possible bugs. Do you have an object caching plugin or something that might be messing with site options?

  • Shawn
    • The Crimson Coder

    I appreciate that I’m the only one that’s reported it, but I like to go by the 1000:1 rule. For every person that reports a problem, there are likely a thousand others experiencing it.

    In any case – it’s still a hijack. No matter how well intentioned you are, the issue is that in many situations the other activity the user is performing is likely to be far more important than activating the key to your plugin. For example, it doesn’t check for POST data, so if I’m setting an option within another plugin, marking a comment as spam, flagging a spam account, enabling another plugin, adding a new user, blog or group, or any of hundreds of other administrative actions…my intended request will NOT be processed, but will instead be redirected thru to the WPMU DEV Dashboard settings page.

    You have to see that this is unacceptable behavior. The right way is to load an information box with an instructional link, not hijack the user request.

  • Aaron
    • Ex Staff

    In any case – it’s still a hijack. No matter how well intentioned you are, the issue is that in many situations the other activity the user is performing is likely to be far more important than activating the key to your plugin.

    It’s only designed to redirect to that page when you click to activate the plugin for the very first time on a WP install. Which would be expected and even desired for usability.

    They highjacking you are experiencing is an artifact as I said of something very weirdly wrong on your install.

    Which means somehow on your server site_options were returning as null for certain admin queries, not a normal or good thing, and possible a symptom of other possible bugs. Do you have an object caching plugin or something that might be messing with site options?

    I’d love to help debug but you’ll need to answer my question.

  • Shawn
    • The Crimson Coder

    You realize that what you’re saying is that it doesn’t matter what else a user might be doing on their site (or if several admins are working simultaneously on different things), the WPMUDEV API key must take priority above all else.

    Debugging won’t fix a system that’s not user-friendly *by design*. You can assert that it’s a problem on my end, but the simple fact is that you simply can’t legitimately justify hijacking a users browser under any circumstances.

    I understand that you believe hijacking an unrelated admin request could be good under some circumstances, but you’re absolutely wrong. This is one of those things that must absolutely not be done. It’s like those sites that refuse to display anything at all if you’re not using the developer’s preferred browser or OS, or if you have a certain plugin installed (like adblock plus) – and frankly, it may as well be considered malware.

    For everyone else, you can disable this “feature” in your mu-plugins with this:

    function RemoveWPMUDEVFirstRedirect () {
    
global $wpmudev_un;
    
remove_action( 'admin_init', array($wpmudev_un, 'first_redirect') );
    
}
    
add_action( 'admin_init', 'RemoveWPMUDEVFirstRedirect', 1 );