Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 13 months ago

#592 closed defect (bug) (fixed)

Cannot log in with 1.5

Reported by: solvingnormal Owned by: matt
Milestone: Priority: high
Severity: blocker Version: 1.5
Component: Security Keywords:
Focuses: Cc:


The latest nightly (1.5-a6, 12/24/2004) doesn't allow login.

When entering an incorrect password, an error is generated (correctly).

When entering the correct password, the browser goes to http://www.solvingnormal.com/wordpress/wp-login.php?redirect_to=%2Fwordpress%2Fwp-admin%2Findex.php
which simply redisplays the original login screen.

Attachments (1)

redirect.diff (4.1 KB) - added by solvingnormal 10 years ago.

Download all attachments as: .zip

Change History (57)

comment:1 @solvingnormal11 years ago

  • Patch set to No

comment:2 @solvingnormal11 years ago

I also want to clarify that after being returned to the login page, I cannot access the admin panel (by manually going to /wordpress/wp-admin/index.php); it simply returns me to the login page. It doesn't appear that a cookie is being set.

edited on: 12-25-04 03:24

comment:3 @BigBen11 years ago

This seems to me to be related to bug #601 and thus might be fixed with my patch...

comment:4 @ryoken11 years ago

sorry, one should never let a friend get a hold of his computer. that last anonyomous note is not true.

comment:5 @solvingnormal11 years ago

This is still persisting for me in the 02/09 nightly.

When I enter the correct username and password, it sends me to /wordpress/wp-login.php?redirect_to=%2Fwordpress%2Fwp-admin%2Findex.php, however this page simply shows the normal wp-login.php page. No cookie is placed onto my computer.

Logging out is similarly futile - it doesn't remove the cookie from my computer. If I remove it manually, I'm stuck out of WordPress until I go back to 1.2.2, login, and then upgrade again.

I have tried all of the advice at http://codex.wordpress.org/Login_Trouble without avail. The only thing that seems to work is downgrading to 1.2.2, logging in, and then upgrading again.

Is there information I can provide to help track this down?

comment:6 @ryan11 years ago

What are your Blog Address and WordPress address set to in Options->General? What is the path set to in your wordpressuser_* and wordpresspass_* cookies? If no cookies are being set, that is indeed a problem although I'm not sure what would be causing that.

comment:7 @solvingnormal11 years ago

Wordpress Options:

Blog Address: http://www.solvingnormal.com
Wordpress Address: http://www.solvingnormal.com/wordpress

Cookie Paths (on both):

Host: www.solvingnormal.com
Path: /

I've created a level 1 user for you to see what this bug looks like..
Logon and password are both "test"

comment:8 @ryan11 years ago

I tried loggin in with your test user and don't see any cookies being set. Just to verify, your functions.php should have wp_setcookie() and wp_clearcookie() at the end of the file. wp-login.php should be using both of these functions. Do you get any errors in your error log when logging in?

comment:9 @solvingnormal11 years ago

Yes - these functions are present in functions.php at the end of the file.

Where would I find an error log? Would I need to ask my hosting provider about that?

Note: When logging in is broken, logging out seems similarly broken. (Both work for me in 1.2.2). Logging out doesn't clear my cookies, it simply redirects me to /wordpress/wp-admin/

comment:10 @ryan11 years ago

Sounds like wp_setcookie and wp_clearcookie aren't even being called. Let's try adding some debug information. Right before this line in wp_setcookie():

setcookie('wordpressuser_'. $cookiehash, $username, time() + 31536000, $cookiepath);

Add the following two lines:

echo "Setting cookies with paths $cookiepath and $sitecookiepath.<br />\n";
When you try to login you should see the debug message.

edited on: 02-11-05 07:04

comment:11 @solvingnormal11 years ago

There were a few lines that matched the one you mentioned.

setcookie('wordpressuser_'. $cookiehash, $username, time() + 31536000, $cookiepath);
setcookie('wordpresspass_'. $cookiehash, $password, time() + 31536000, $cookiepath);

if ( $cookiepath != $sitecookiepath ) {

setcookie('wordpressuser_'. $cookiehash, $username, time() + 31536000, $sitecookiepath);
setcookie('wordpresspass_'. $cookiehash, $password, time() + 31536000, $sitecookiepath);


I placed the line you gave me right above the first one.

It returned:

Setting cookies with paths / and /wordpress/.

edited on: 02-11-05 13:46

edited on: 02-11-05 13:46

comment:12 @anonymousbugger11 years ago

Tried various nightly builds and can confirm the above issue across all my tests. Cookies aren't set.

comment:13 @ryan11 years ago

Hmm, php's setcookie() is not setting the cookies, apparently. What version of php is being used? Trying commenting out or deleting the following lines in wp_setcookie() and see what happens.


if ( $cookiepath != $sitecookiepath ) {

setcookie('wordpressuser_'. $cookiehash, $username, time() + 31536000, $sitecookiepath);
setcookie('wordpresspass_'. $cookiehash, $password, time() + 31536000, $sitecookiepath);



comment:14 @anonymousbugger11 years ago

PHP Version 4.3.3 - You can see the info at

Commenting out those lines didn't do anything.

comment:15 @solvingnormal11 years ago

Sorry, that last anonymous note was from me.

comment:16 @ryan11 years ago

  • Severity changed from major to blocker

comment:17 @ryan11 years ago

  • Summary changed from Cannot log in with 1.5-a6 to Cannot log in with 1.5

comment:18 @anonymousbugger11 years ago

I am also having this problem. I have also tried all solutions at http://codex.wordpress.org/Login_Trouble without success. It definitely seems to be a cookie issue as they are never set. Different browsers and different machines makes no difference. This only occured after upgrading 1.3 to 1.5. Was there a change in the method or function for setting cookies from 1.3 to 1.5?

I have checked the values of 'siteurl' and 'home' in the database and they are correct.

comment:20 @sidvorak11 years ago

Hmm... that looks promising. I am using IIS. I'm just stumped as to why this has become an issue with the 1.5 release.

I will try to change my wp-login file as was refernenced ( http://wordpress.org/support/topic.php?id=23250#post-133550 )

btw: I made this post
02-16-05 21:20

edited on: 02-16-05 23:58

comment:21 @sidvorak11 years ago

Ok, I commented out the header line in wp-login as follows. The cookie was set and I was able to access the admin by manually typing the url. Yay! However, any ideas on an alternative to the header() redirect?

if ($user_login && $user_pass) {

$user = get_userdatabylogin($user_login);
if ( 0 == $user->user_level )

$redirect_to = get_settings('siteurl') . '/wp-admin/profile.php';

if ( wp_login($user_login, $user_pass, $using_cookie) ) {

if (! $using_cookie) {

wp_setcookie($user_login, $user_pass);

do_action('wp_login', $user_login);

commented out--->header("Location: $redirect_to");


} else {

if ($using_cookie)

$error = ('Your session has expired.');



comment:22 @sidvorak11 years ago

okee...got it working. For the logout case:
case 'logout':

header('Expires: Mon, 11 Jan 1984 05:00:00 GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-cache, must-revalidate, max-age=0');
header('Pragma: no-cache');
echo "<meta http-equiv='refresh' content='0;URL=wp-login.php'>";
header('Location: wp-login.php');

and instead of header("Location: $redirect_to"); aafter the cookie set in the login case changed to:
echo "<meta http-equiv='refresh' content='0;URL=$redirect_to'>";

Look good?

comment:23 @anonymousbugger11 years ago

solution provided by sidvorak do indeed work!

comment:24 @solvingnormal11 years ago

I can confirm that sidvorak's change solved the problem for me as well.

Can this be added to the code, or would it be problematic for something else?

comment:25 @anonymousbugger11 years ago

the header redirect affects the whole installation. on some pages the pages don't just reloaded and cause quite a issue. can the developers look into it and implement this through out the whole wordpress?

comment:26 @anonymousbugger11 years ago

Here are a list of edits that fixed this same issue for me. <a href="http://www.simmonsconsulting.com/wordpress/?p=160">Fixing WP 1.5 when running on IIS 5</a>. The bug is in IIS, which is documented <a href="http://support.microsoft.com/kb/q176113/">here</a> -- it has to do with setting cookies and doing a header('Location:') redirect in the same PHP script. Any chance of these getting into CVS?

edited on: 02-17-05 16:15

comment:27 @dougal11 years ago

Yup, it's an IIS issue.


I wonder if doing something like this would cause IIS to act correctly:

@header("Status: 302 Redirect",302);

I'm not sure if the PHP module for IIS will override the default behavior or not if you manually set Status. Worth a try. Anybody got a test platform to try it on?

comment:28 @dougal11 years ago

Ah, Toby posted his workaround between the time I started researching and the time I posted ;)

Using "Refresh" instead of "Location" is a pretty valid approach, too. But I'd still be curious to see if manually setting "Status" in conjuction with "Location" will work.

comment:29 @anonymousbugger11 years ago


(This is Toby again ... Sorry for the anonymous posting, I haven't signed up yet)

I ran the following test script which redirects to an ASP page that lists all cookies set by the server, and it does NOT set the cookies (a header sniffer reveals the same thing, the set-cookie headers are not sent.):


setcookie("000", "This is the cookie string", time() + 31536000, "/");
header("Status: 302 Redirect",302);
header('Location: again.asp');


edited on: 02-17-05 16:53

comment:30 @dougal11 years ago

Arg, that's what I get for using my organic memory cells and not verifying with research *first*...

The proper way to override the HTTP status is like this:

header("HTTP/1.0 302 Redirect");

(found at http://php.net/header)

Could you try that instead of the Status header, and see if it makes a difference? Thanks for being our guinea pig!

comment:31 @anonymousbugger11 years ago

(This is Toby)

The following code sends NO cookie:


setcookie("000", "This is the cookie string", time() + 31536000, "/");

header("Status: 302 Redirect",302);

header("HTTP/1.0 302 Redirect");
header('Location: again.asp');


comment:32 @toby11 years ago

Finally got registered. Any other ideas? One thing that would be nice is to compartmentalize the header('Location:') calls into a single function so that it could be changed in one place -- redirectto("wp-admin");

Take into account IIS issues in cookies and redirection
function redirectto($wheretogo)

if (strstr(php_uname(), 'Windows'))

header("Refresh: 0;url=$wheretogo");


header("Location: $wheretogo");


comment:33 @anonymousbugger11 years ago

That sounds like a really good idea Toby. Since these calls are scattered all over doing something like that would make fixing this issue for IIS alot less painful.

What I'm stumped about is why wasn't this discovered before the 1.5 release? Wasn't it tested on IIS?

comment:34 @solvingnormal11 years ago

I reported this originally on 12/25 - way before the 1.5 official release. It never got looked at, I guess.

comment:35 @ryan11 years ago

It was looked at, just not figured out. We need an IIS testbed and more IIS beta testers.

comment:36 @sidvorak11 years ago

I went through and replaced all instances of the header redirect with a call to the function Toby described.
function redirectto($wheretogo)

if (strstr(php_uname(), 'Windows'))

header("Refresh: 0;url=$wheretogo");


header("Location: $wheretogo");


It works great.

comment:37 @ryan11 years ago

php_uname may not be appropriate since Apache runs on Windows too.

comment:38 @toby11 years ago

Any problems using the 1.2.2 method and adding a variable to vars.php, as in:

$is_IIS = strstr($_SERVERSERVER_SOFTWARE?, 'Microsoft-IIS') ? 1 : 0;

Then, just check $is_IIS?

edited on: 02-18-05 00:58

comment:39 @ryan11 years ago

I think that sounds good. I'd like to get some input from Matt to see if there was a reason we removed it, or if we just got overzealous with housekeeping. Regardless, alternative methods have not presented themselves, and we can't leave IIS logins broken.

comment:40 @sidvorak11 years ago

I like the variable idea too. However, is it really a problem if the alternate redirect method is used on an Apache server?

comment:41 @dougal11 years ago

sidvorak: the "Refresh" header method just isn't as "clean" as a real HTTP redirect, and there may be oddball user agents that don't implement it (I'm mainly thinking about browsers on portable devices). I think I'd prefer that we continue to use a true redirect by default, and just special case IIS as we've been discussing.

I also second the motion to move the redirects into a separate WP function, in case we run up against other special cases in the future.

edited on: 02-18-05 14:28

comment:42 @ryan11 years ago

Matt is going to resurrect the 1.2.2 functionality and package it in a wp_redirect() function.

comment:43 @ryan11 years ago

  • Owner changed from anonymous to matt
  • Status changed from new to assigned

comment:45 @ryan11 years ago

  • Priority changed from normal to high

comment:46 @anonymousbugger11 years ago

Will there be an update here when this has been fixed and the finished code is available?

comment:47 @ryan11 years ago

Yes, when the bug transitions to Resolved that means a fix has been committed. This bug will be fixed for 1.5.1.

comment:48 @ryan11 years ago

Attached: Patch introducing wp_redirect() and addressing all troublesome redirect locations indentified by Toby.

comment:50 @toby11 years ago

You need to change line 30 of wp-login.php as well, otherwise user's will never be able to log out (the login cookie will not be cleared by wp_clearcookie())

change this:
30: header('Location: wp-login.php');

to this:
30: wp_redirect('wp-login.php');

comment:52 @toby11 years ago

Wow, that was fast! I've incorporated these changes with my current site (using the current CVS versions.) Is it okay if I offer a zip file containing these files for IIS users who are uncomfortable with editing the files?

comment:53 @ryan11 years ago

Sounds great. Thanks for your help.

comment:55 @ryan11 years ago

  • fixed_in_version set to 1.5.1
  • Resolution changed from 10 to 20
  • Status changed from assigned to closed

@solvingnormal10 years ago

comment:56 @ircbot13 months ago

This ticket was mentioned in IRC in #wordpress-dev by netweb. View the logs.

Note: See TracTickets for help on using tickets.