problem with siteurl being changed in 1.2.1

[astronomer]

A new problem appeared with the 1.2.1 upgrade. I run behind a reverse proxy server, with siteurl set to the public address of the site. With the new 1.2.1 upgrade, code has been added to wp-login with the comment “If someone has moved WordPress let’s try to detect it.” This code finds that HTTP_HOST . REQUEST_URI (which are set to the internal names) doesn’t match siteurl, and it promptly edits the options database, changing siteurl to the internal name.
This creates the very puzzling behavior that everything looks fine until some user tries to log in, and then not only does the login fail but the site breaks for everyone else until you go into the mysql database and fix things by hand.
Simple solution was to comment this line out of wp-login.php. Getting reverse proxies running properly is hard enough without a too-smart program changing things behind your back! Am I correct this change is meant to be a convenience, and not some obscure security fix?

[Anonymous]

Yes – I had this same problem. Thank you for your post – it made it quicker to find.
I don’t think programs messing around with these URIs is a good thing. It can easily break anything unique someone might have done with their site.

[Anonymous]

Damn i had this problem too. I was totally confused why it was resetting my siteurl. Thanks for the heads up. Yes it’s broken if your proxying.

[dbowen]

Ah. This may be what has caused my siteurl to reset itself to:
http://www.geekrant.org/wp-login.php/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/wp-images/smilies/
…I think you can probably spot why this is wrong!
It’s most visible because it can’t see the layout css, but it also breaks the login. What’s strange is that I haven’t seen the same behaviour on other blogs on the same virtual server. Perhaps it’s only triggered by going to the login page, as well as proxying?
I got paranoid and changed my database password, but I’ll try commenting out as above. Thanks.
Daniel

[Anonymous]

Yup, this killed my website as well. This code needs to be looked at and fixed or removed, imho.

[Mark (podz)]

Turnip’s workround:
http://turnipspatch.com/archives/2004/10/19/killing-the-word-wide-web/

[deadgoon]

I commented out the lines in wp-login.php and added some lines to my .htaccess file as suggested by Turnip.
Now I can’t access my site or login because cookies may be getting blocked. I cleared my cookies, and I tried adding my address to the exceptions list but still can’t connect.
I’m getting just a little bit frustrated with this 🙁

[alpha]

deadgoon,
I don’t think you had to take both actions but I’m not sure. My blog was completely broken too and by following Turnip’s fix, it seems to be fixed now.

[desertjo]

Quick question (and it’s not one I want to try out, obviously 🙂
that code doesn’t get invoked on an invalid login, does it? meaning, could someone who knows this bug exist take down someone else’s site just by trying to login to the short URL with a fake user/pwd, while not actually logging in?
it only happens if someone successfully logs in from the short url?
just checking. the blog i admin for has been hit with an inordinate amount of spam lately and some other attacks, and the thought of anyone trying that before i had a chance to comment out those lines kinda gave me the chills for a second there.

[Anonymous]

it happened to me too but got fixed by intself, strange huh?

[shelleyp]

Not strange, as detailed in this support thread.

[James Huff]

For those who stumble along this thread, this is a known bug. You will need to manually fix your ‘site_url’ and ‘home’ values via phpmyadmin: http://www.tamba2.org.uk/wordpress/site-url/
Then, upgrade to WP v1.2.2 [or the latest Nightly Build].