This is almost certainly a cookie problem. Chances are, the cookie domain isn't getting set properly. (That's why it works other places, but not in the subdomain.)

I learned about this when working with another project that suddenly refused to cooperate when put on a subdomain. Unfortunately, with cookies, once I learn it and get it working, I tend to forget what I did to make it work...

What do the links look like? Are they http://host.com/subdomain/blah or http://subdomain.host.com/blah?

They are http://subdomain.domain.com.

Thanks for any input. It's really frustrating when I've installed B2E so many times successfully only for this to happen out of the blue.

The Installation Support FAQ here:

http://b2evolution.net/man/2004/06/16/support_faq

addresses exactly your question, doesn't it? Did the FAQ's solution not help?

Brian

Brian,

Thanks for your reply. Yes I checked that and double checked it and still no joy.

Also there's a sticky set of FAQs in the forum and I went through those steps too.

Again thanks for at least being interested enough to try and help. :D

Just a couple of simple things to check...

1. When you go to your URL of subdomain.domain.com, and then go to the back office, does the URL showing in your browser's address window show as subdomain.domain.com/blogs/admin/whatever.php?blog=N or does it change to something else? Such as...

www.domain.dom/subdomain/blogs/admin/whatever.php?blog=N

2. If you check your browser or firewall privacy control area for cookies, does your subdomain.domain.com cookie show up? Is it from the same URL as the baseurl that you set in the conf/_config.php file? If not, can you check to see if that subdomain's URL is being blocked? If the URL is not being blocked and the cookie isn't in your cookie list, perhaps the cookie isn't being set.. Check conf/_config.php to see what baseurl is set there and conf/_advanced.php for cookie naming conventions and see if anything odd might be there.

I hope all works out for you.

The FAQ entry on preventing the continous login problem mentions (as does the config file) that you should use http://localhost or a fully qualified network name http://machine.domain.whatever:port.

Well, after a few hours of being stubborn, not believing the posts, then giving in and trying cookie settings ... I discovered the problem for me was a simple one.

I was running IIS (we all make mistakes) on port 80 and Apache on port 81. No good reason, just history. Turns out that http://localhost:81 does not get recognized correctly. Changing the port to 80, which allowed me to not mention it, fixed the problem.

Perhaps others can profit from my experience. Else, my only comfort is that I have finally retired IIS. Never missed it since I have Apache.

That's true, using localhost as the machine name with a port other than 80 or 8080 won't work properly in a plain Apache config.

If someone can't change to port 80 or 8080 for a localhost type of intallation, they can use the fully qualified domain name (FQDN) for the machine hosting b2evolution, and add the IP address of that machine to the etc/hosts file of that machine and any other machine on your local area network that they want to access that machine.

In windows, the path to the etc subdirectory containing the hosts file should be something like:

%systemroot%\system32\drivers\etc\hosts

One can find the system root for the machine by going to a command prompt window and typing

echo %systemroot%

It should be WINNT for W2K and windows for XP.

Edit that file with a plain text editor such as Notepad and add the line

192.168.1.nnn	hostname.domain.tld			#required for Apache & Blogs testing

Using the proper IP address for the machine, which can be found by typing ipconfig at the command prompt. And the machine should be behind a firewall to use a test IP address similar to the one given, or if the machine is accessible directly from the Internet, it should have a resolvable IP address and FQDN, which should be used.

Sorry to waste bytes for those who know this, but it may be useful for those who don't.

I've done it all. Everything everyone has mentioned, but still get constantly asked to login on everything. There has to be something else besides cookies, as I know for a fact my cookies have been cleared (multiple times).

Is this not considered a bug? >:(

No, because it is (probably) your cookies. What have you actually tried to do? Have you tried in more than one browser? I used to have this problem, and I solved it by using the same baseurl as what I was using to access my backoffice.

I've cleared my cookies (through the browser and through Explorer). I've tried IE 6, Avant Browser (IE on steroids) and Mozilla Firefox. Firefox showed that there were actually two cookies written, one is a session cookie, the other is odd, something called "evo_style", that is written on post (any form post, save a user as an example).

My browsers are all set to prompt for cookies, and I've verified they are being written.

I had my baseurl set to http://localhost, no workie. I added a hosts entry to my machine (127.0.0.1 media.home.org), and set my baseurl to be http://media.home.org/b2evolution/blogs. No luck there either.

I know that cookies are working fine, as I have other PHP based software running (TextPattern and pMachine). b2evolution and WordPress both fail to properly log in.

Have you tried this on a remote server? If two different programs fail, it could be something wrong with your setup...

Also, have you tried specifying the port as well?

I mean, I have this running on http://localhost on apache / win with no problems...

I haven't tried remote, haven't had the option of that at this point. Well, we can say two different programs, but WordPress and b2Evolution have the same background (b2 is now WordPress), so, the failure on each of these could be for the same reasons.

Did try the port, no workie. I'm on Apache/Win (FoxServ 3.0), but no avail on this problem.

Somewhat depressing.

It's because b2evo and WP are set up to prevent XSS hacks by limiting the cookie domain and path. (Also, the XHTML and Security checkers are important for that, too.)

isaac wrote:

This is almost certainly a cookie problem. Chances are, the cookie domain isn't getting set properly. (That's why it works other places, but not in the subdomain.)

Have you gone through your conf files and made sure that there's nothing invalid in there? Start with _config.php, and also check _advanced.php and _admin.php at least. Read the comments in there - they're helpful. Add some echo statements to debug and find out what's going on. That sorta thing.

All this stuff about hosts files and ports and whatnot is unwarranted at this point. What is the cookiedomain that b2evo is trying to use? What domain is your site on? Until you have investigated the most likely source of the problem, it's fruitless to try other steps.

I have b2evolution running on my local machine on port 80 with either IIS or Apache, depending on my mood at the moment, and on 8080 with another different Apache installation. It's using three different versions of PHP (4.1, 4.2, and 4.3 - I'll be replacing the 4.3 with 5.0 soon.) I have run it on a godaddy site, and 2 subdomains. It CAN be done, with almost any server setup - it's just not configured properly in this case, and it should be pretty clear what is not right. Until that's checked and verified, there's no point messing with anything else.

This is always on my local machine. Machine name: media

url I go to: http://localhost/b2evolution/blogs/admin

_config.php (PHP script tags removed):

/**
* This is b2evolution's main config file
*
* You need to edit this file to your settings before attempting to install the database!
* Last significant changes to this file: version 0.9.0.2
*
*
* Reminder: every line starting with # or // is a comment, multiline comments are
* surrounded by '/*' and '* /' (without space).
*

* IMPORTANT: Take special care not to erase quotes (') around text parameters
* and semicolums (;) at the end of the lines. Otherwise you'll get some
* "unexpected T_STRING" parse errors!
*

* Contributors: you should override this file by creating a file named _config_TEST.php
* (see end of this file)
*
* b2evolution - {@link http://b2evolution.net/}
* Released under GNU GPL License - {@link http://b2evolution.net/about/license.html}
* @copyright (c)2003-2004 by Francois PLANQUE - {@link http://fplanque.net/}
*
* @package conf
*/

/**#@+
* MySQL settings. Fill in your database details (check carefully or nothing will work!)
*/
define( 'DB_USER', 'brian' ); // your MySQL username
define( 'DB_PASSWORD', 'blur' ); // ...and password
define( 'DB_NAME', 'b2' ); // the name of the database
define( 'DB_HOST', 'localhost' ); // mySQL Server (typically 'localhost')
/**#@-*/

/**
* If you want to be able to reset your existing b2evolution tables and start anew
* you must set $allow_evodb_reset to 1.
*
* NEVER LEAVE THIS SETTING ON ANYTHING ELSE THAN 0 (ZERO) ON A PRODUCTION SERVER.
* IF THIS IS ON (1) AND YOU FORGET TO DELETE THE INSTALL FOLDER, ANYONE WOULD BE ABLE TO
* ERASE YOUR B2EVOLUTION TABLES AND DATA BY A SINGLE CLICK!
*/

$allow_evodb_reset = 0; // Set to 1 to enable. Do not leave this on 1 on production servers
/**
* $baseurl is where your blogs reside by default. CHECK THIS CAREFULLY or nothing will work.
* It should be set to the URL where you can find the blog templates and/or the blog stub files,
* that means index.php, blog_b.php, etc.
* Note: Blogs can be in subdirectories of the baseurl. However, no blog should be outside
* of there, or some tricky things may fail (e-g: pingback)
*

* IMPORTANT: If you want to test b2evolution on your local machine, do NOT use that machine's
* name in the $baseurl!
* For example, if you machine is called HOMER, do not use http://homer/b2evolution/blogs !
* Use http://localhost/b2evolution/blogs instead. And log in on localhost too, not homer!
* If you don't, login cookies will not hold.
*/

$baseurl = 'http://localhost/b2evolution/blogs'; // IMPORTANT: NO ENDING SLASH !!!

/**
* Your email. Will be used in severe error messages so that users can contact you.
* You will also receive notifications for new user registrations there.
*/

$admin_email = 'cheshyrekatt@mailserver.com';

/**
* Once you have edited this file to your settings, set the following to 1 (one):
*/

$config_is_done = 1;

# IMPORTANT: you will find more parameters in the other files of the /conf folder.
# IT IS RECOMMENDED YOU DO NOT TOUCH THOSE SETTINGS
# UNTIL YOU ARE FAMILIAR WITH THE DEFAULT INSTALLATION.
#

# It is however strongly recommended you browse through these files as soon as you've
# got your basic installation working. They'll let you customize a lot of things!

# DO NOT EDIT THE FOLLOWING!

@include_once dirname(__FILE__).'/_config_TEST.php'; // Put testing conf in there (For testing, you can also set $install_password here)
require_once dirname(__FILE__).'/_advanced.php'; // advanced settings
require_once dirname(__FILE__).'/_locales.php'; // locale settings
require_once dirname(__FILE__).'/_formatting.php'; // formatting settings
require_once dirname(__FILE__).'/_admin.php'; // admin settings
require_once dirname(__FILE__).'/_stats.php'; // stats/hitlogging settings
@include_once dirname(__FILE__).'/_overrides_TEST.php'; // Override for testing in there

This topic started with a problem from chief123 and then went to a similar problem from pdelbar, and now from cheshyrekatt.

chief123 - did you fix your problem? If so, how?

pdelbar fixed the problem by changing the port to which Apache was listening from port 81 to port 80. Another way to allow Apache to listen to a non-standard port is to use a FQDN rather than localhost, with the port number being used. [See my second post in this topic.] Standard ports for web services are 80, 8080 and [for SSL] 443.

We currently have b2evo 0.8.9, 0.9.0.5 and 0.9.0.10 running in 8 different configurations on three different operating systems: Win2K, WinXP and VDE on Solaris, and under various domains, subdomains and redirected domain names. and listening to various ports. We're using Apache 1.3 and a bastardized version of Apache somewhere between 1.3 and 2. They're all working fine.

cheshyrekatt - did you check what cookies are actually being set in your browser(s)? [See my first post in this topic.] I agree that your cookies aren't being set properly. The question is why not, and how are they being set.

Two cookies are being written (info from FireFox).

One is session (as mentioned above). Its contents are:

Name: cookieb3evopass
Content: (Removed for security reasons - Isaac)
Host: localhost
Path: /b2evolution/blogs/
Expires: at end of session

The other is as follows (this is on changing pages in the admin)

Name: evo_style
Content: Variation
Host: localhost
Path: /
Expires: at end of session

Hmm,,,

I'm not an expert, so someone else should comment. I will say this.

The cookies on our test machines are set to expire one year from being set. This is the default. You might check your conf/_advanced.php around line 233...

/**
 * Expiration for cookies.
 *
 * Value in seconds, set this to 0 if you wish to use non permanent cookies (erased when browser is closed).
 */
$cookie_expires = time() + 31536000;		// Default: one year from now

/**
 * Expired-time used to erase cookies.
 */
$cookie_expired = time() - 86400;				// Default: 24 hours ago

We also have cookieuser and cookiestate in addition to cookiepass. These three cookies are the username, last skin used and password. The evostyle cookie is the last skin used for the back office.

To those in the know, could the lack of the user cookie be the problem, or is the expiry being the "end of session" be the problem? Or something else?

The setting of cookieb2evouser is failing. I looked into echoing a few things, and I found the code in _functions_users.php where that cookie is set. If I uncomment line 80, to echo the info that is being sent for the user cookie ($cookie_user, $log, $cookie_expires, $cookie_path, $cookie_domain), all the displays is "cookieb2evouseradmin" in the html render, then I get warnings galore about not being able to set the cookie. (_functions_users.php on line 81
setcookie cookieb2evouser failed!, then again in line 83)

Success!

Not through anything but ridding my system of FoxServ 3.0, and installing WAMP 5.1.1.

Evidently, there is some weirdness in the configuration of FoxServ's version of Apache or PHP. Works wonderfully in the new version though. So, I'm a much happier camper now.

Many thanks to the efforts of those trying to help me out.

I had a difficult time with login craziness too. I am new to b2 and thought I had set everything correctly. I read all of the post in this thread and still nothing. I clearly did not understand the required information for host name. I put in just the name I use internal even though it has a FQDN. It turns out that the name required is the same as that which is returned by "hostname" (under Linux). problem solved. :D

Thanks for a very impressive software package.

using ver 0.9.10

change in the _conf file

from
$baseurl = http://localhost/b2evolution/blogs;

to
$baseurl = "http://'.$SERVER_NAME.'/b2evolution/blogs';

this at least got it to work remotely for me. I'm playing with other settings to see how to fix it. I had the same problem. I have b2evo working on 2 other sites on my server. But one just doesn't like to stay logged in.

Kevin,

That's because "localhost" = "this machine."
When i'ts remote, the server is not localhost.

$SERVER_NAME will only work if register_globals is on, which is frowned upon.

if I disable global varibles how would i use session with superglobals? or .htasccess.