Cannot log in with 1.5

[solvingnormal]

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.

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

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

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

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?

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.

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"

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?

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/

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:

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

edited on: 02-11-05 07:04

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

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

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.

<pre>

if ( $cookiepath != $sitecookiepath ) {

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

}

</pre>

PHP Version 4.3.3 - You can see the info at  http://www.solvingnormal.com/phpinfo.php

Commenting out those lines didn't do anything.

Sorry, that last anonymous note was from me.

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.

Using IIS?

 http://wordpress.org/support/topic.php?id=23250#post-133550

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 anonymousbugger 02-16-05 21:20

edited on: 02-16-05 23:58

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");

exit();

} else {

if ($using_cookie)

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

}

}

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

wp_clearcookie(); do_action('wp_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'); exit();

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?

solution provided by sidvorak do indeed work!

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?

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?

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

Yup, it's an IIS issue.

 http://support.microsoft.com/kb/q176113/

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?

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.

dougal,

(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.):

<?php

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

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!

(This is Toby)

The following code sends NO cookie:

<?php

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

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

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

?>

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");

else

header("Location: $wheretogo");

}

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?

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

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

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");

else

header("Location: $wheretogo");

}

It works great.

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

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

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.

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

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

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

 http://www.simmonsconsulting.com/wordpress/?p=160

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

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

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

 http://trac.wordpress.org/changeset/2436

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');

 http://trac.wordpress.org/changeset/2440

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?

Sounds great. Thanks for your help.

No problem. Thanks for ya'lls speedy work! <a href=" http://www.simmonsconsulting.com/wordpress/?p=164"> http://www.simmonsconsulting.com/wordpress/?p=164</a>