responseRedirect causing 404

[tenants]

Hmm, never looked into it, but yes I've seen these permission issue with 1.2.0 for superadmin (id=1).. but I haven't seen them on 1.2.1
I have never looked into it... but it does sound like something related to cached permissions /user/usergroup permissions (and it could be a core issue for 1.2.0)

It would be good to know what version Arty and Daniel a running (this could still be a Red Herring)

 

[Daniel Hood]

.....I'm on XenForo 1.2.0, haven't run the upgrade yet.....

Seriously though, it must be something related to the super admin accounts on v1.2.0

 

[Chris D]

Ok.

Forget everything I said.

I am reproducing this now in XenForo 1.2.1.

My upgrade before was promoting my account into a group it was already in (so no changes took place). I set up a new usergroup, set that as an additional group in the Upgrade and then run the code.

I'm looking through the code now.

 

[tenants]

Edit : ah

Is it still only reproducible with the super-admin?

I've still no idea why yet, but I'm off to Greece now

... and there I go

 

[Arty]

I should have added, I tested it twice. Both on 1.2.1. Once with my super admin account and once as a normal user. Both worked fine.

When you get the error, from what @Arty said, the address in the address bar of your browser is account/upgrades, correct? So effectively the redirect has taken place at that point ... and also it seems as though the downgrade executed.

If you then refresh the page, do you get properly redirected without error?

Yes, that's correct. And you are right about super admin - tested with normal user account and I don't get errors. Forum is running 1.2.1

 

[Chris D]

Probably one for @Mike to look at then. Very odd.

 

[Arty]

Thanks a lot for help!

As temporary solution I've changed code to this:

    if ($userId == 1)
     {
       // Workaround for XenForo 1.2 bug
       return $this->actionUpgrades();
     }
     return $this->responseRedirect(
       XenForo_ControllerResponse_Redirect::SUCCESS,
       XenForo_Link::buildPublicLink('account/upgrades')
     );

but I'm still trying to figure out which function is causing it to file a bug report. So far traced it to XenForo_ControllerPublic_Abstract::_preDispatchType(). For some reason it re-routes to XenForo_ControllerPublic_Error with action set to "Nopermission" and doesn't return to parent function.

 

[Chris D]

Just an odd theory. In that actionNoPermission do a Zend_Debug::dump on the XenForo_Visitor instance.

Is there anything odd about usergroups or permissions dumped in the output?

 

[Chris D]

OK.

I can answer my previous question and this is the problem:

Very shortly after (1-3 seconds) the usergroup change has taken place, the $visitor object for a Super Admin contains a blank "global_permission_cache" and a completely blank "permissions" array.

Yep... the Super Admin momentarily loses all of his permissions.

I haven't worked out the cause, but that is the problem. The process of downgrading an account upgrade causes all permissions to be removed from the $visitor object, but only for Super Admins...

EDIT: It is not just Super Admins. I set $config['superAdmins'] to another user ID and did the process again, still get an error.

 

[Chris D]

Partial dump of XenForo_Visitor::getInstance():

...
["global_permission_cache"] => string(0) ""
...
["permissions"] => array(0) {
}
}

 

[Daniel Hood]

EDIT: It is not just Super Admins. I set $config['superAdmins'] to another user ID and did the process again, still get an error.

.... I thought you said this worked for you as long as you weren't super admin?

 

[Chris D]

It seems to work with normal users as far as I can tell right now.

But it gives me an error even if my Admin account is no longer a Super Admin.

 

[Mike Edge]

Tested and got this as well. Made another user and made it SU no problem. It appears it is not a SU issue but instead related to if UserID=1