[geeklog-devel] Plugin upgrade failure (was: More automation)

[Dirk Haun]

Rouslan Placella wrote:

> The token mismatch isn't actually where you think it is.

Yep, you're right.


> However we lose a message, though I'm not sure
> what it is or how important...

First of all, we both seem to test the same situation, i.e. upload the 1.0.0 version of the plugin and then immediately upload the 1.1.0 version. The successful initial install will result in message 44 being displayed, i.e. the current URL ends in ?msg=44 when we upload the 1.1.0 version.

The problem then is this:

Sun May 22 10:01:07 2011 - created token b0a28de3bfe5f32eeb1b503446755aa1 for URL http://example.com/admin/plugins.php 
Sun May 22 10:01:07 2011 - mode=continue_upgrade, Referrer: http://example.com/admin/plugins.php?msg=44 
Sun May 22 10:01:07 2011 - checking token b0a28de3bfe5f32eeb1b503446755aa1 
Sun May 22 10:01:07 2011 - > referrer didn't match, expected http://example.com/admin/plugins.php but got http://example.com/admin/plugins.php?msg=44

SEC_createToken uses COM_getCurrentURL to get the current URL. But the reconstructed URL is missing the ?msg=44 bit, probably because we're in the middle of a POST request at this point.

Ugh. I don't really want to fiddle with COM_getCurrentURL at this point.

Suggestion: We leave things as they are (i.e. no token check for this upgrade scenario) for 1.8.0 and try to fix COM_getCurrentURL for 1.8.1. I think the upgrade is reasonably safe as it is - it's vulnerable to CSRF but with the sanity checks in place, I don't see how you could do any damage here.

Comments, other opionions, other solutions?

bye, Dirk