Not sure what the correct subject should be here... but figured this might get attention 8-)

Okay, I've been trying to setup an auto-login script (i'm in a single sign-on enviro). I have my users setup properly in the UBB DB. If I go through all the login pages using UBB everything works fine. When I go through my login script (behind the scenes) I can get to the first page (whichever, start_page, ubbthreads, etc) with no probs, full auth. But any other page thereafter will not authenticate the user.

After much time going through all the UBB login code, and initial pages, and debugging, I've discovered that the reason the subsequent pages don't work is that the cookies are being dropped.

Now here is the interesting part, if I go through my login script after a POST from another page, everything works fine and persists the cookies on all pages.

So it looks like the login script works, but the cookies are wiped out unless I do a POST from a previous page.

Is there something I just don't know about how PHP or UBB is handling cookies? Please help!!!

Any help would be much appreciated. Thanks.

-ufid

Hard to say without knowing how you set the cookies and what values the cookies aktually have in your browser.

Here is how I set the cookies (same code as ubbt.inc):

srand((double)microtime()*1000000);
$newsessionid = md5(rand(0,32767));
$autolog = md5("$Uid$pass");

setcookie("{$config['cookieprefix']}w3t_myid","$Uid",time()+$config['cookieexp'],"{$config['cookiepath']}");
setcookie("{$config['cookieprefix']}w3t_key","$autolog",time()+$config['cookieexp'],"{$config['cookiepath']}");
setcookie("{$config['cookieprefix']}w3t_mysess","$newsessionid","0","{$config['cookiepath']}");
setcookie("{$config['cookieprefix']}w3t_language","$ubbt_language",time()+$config['cookieexp'],"{$config['cookiepath']}");
setcookie("{$config['cookieprefix']}ubbt_pass","",time()-3600,"{$config['cookiepath']}");
setcookie("{$config['cookieprefix']}ubbt_dob","",time()-3600,"{$config['cookiepath']}");

I'm including the ubbt.inc (or main.inc) file to be able to use some of the variables.

Like I said, the first page i go to is fine, and the cookies seem to be there. It's as soon as click on any link to another page, it seems that the cookies are dropped.

If the cookies aren't making it to my browser, than I don't understand how to set the cookies any differently. And especially considering that without making any code changes, if I go through my login script via a POST from a previous page, then it ALL works. I'm very stumped.

-ufid

Do you store the new session id in the database after setting the cookie?

Yes, it's being stored in the database.

Like I said, it works 100%, everything works fine, ONLY when I go to the login script via a POST operation. I'm not even passing anything via the POST, just the action of doing a POST seems to properly initialize and persist these cookies.

So worst case, I just setup a dummy page that submits itself to my login script and everything else will work... but this just isn't a clean way of doing it. There must be something I'm missing about how cookies are initialized and how they work on the server end of things.

It's hard to say without having the scripts right in front.
Sounds as if the cookies aren't set correctly under certain conditions.

What browser do you use?
If you use Mozilla, you could go into the cookie manager and see if the cookies are set and what values they have.

Okay, I've narrowed it down even further.

I'm using IE5.5.

When I go directly to my login script, it has a left over cookie from some previous session, but this shouldn't matter. I create a new sessionID and when I check the browser, sure enough the new wt3_mysess cookie is there and set.

As soon as I go to any other page, the cookie seems to disappear. The browser doesn't seem to send it, and so of course I am essentially logged out.

Now, when I go through a dummy page first and do a POST op to get to my login script, there are no previous cookies present. A new sessionID is created like before, and like before the cookie is sent to the browser and the browser sees it. The difference here is that no matter what other page I go to, the cookies persist, the way they should.

What is a POST doing different than just a regular request to a page?

To make it more interesting, this is only happening in IE5.5. I just installed Mozilla 1.6 and it works both with or without the dummy page.

The frustration continues...

Are you using the spider mod for search engine friendly urls?

What value is your cookiepath set to?

Are your links all pointing the same place. ie www.yourdomain.com or youdomain.com
If some things point to one, and others point to the other, that will cause you to have login problems.

A link to your site for closer examination would be useful as well.

Well... turns out that it might have something to do with using the same name as one of the ubb files (start_page.php).

I'm not using 'login' or 'start_page', and so I used the start_page name. Still not sure why it would work one way, but not the other. Right now my theory is this, when I first tried ubb for a test drive, my browser (or server) cached, stored, or somehow recorded info for that page. So that when I went to that page directly it wouldn't properly set cookies (even though it was my own scripted page). I'm sure a quick test of completely flushing out everything (if that's even possible) might prove it either way.

By default, users login through the login page, and then a POST request is made to start_page.php.

Anyhow, I renamed the page to something completely unique, and now it works no matter how I try to access it, request, through a POST or GET, redirect... it just works. So I'm not going to tempt the browser/server cookie gods anymore and just accept it.

After searching around other forums and the internet, I found others have had similar problems with cookies on IE, while not on Mozilla (or other browsers).

I'll be a little happier if everything still works tomorrow morning 8-)

Thanks anyone who gave this a thought and tried helping out.

-ufid

Arrrrrrggggghhhhh.....

Okay... I played around with the cookiepath as suggested.

Now, it was allllll working without messing with the
cookiepath, unless I tried bypassing the login page, or a page that does a POST op. But as soon as I tried sending in Query_Vars, it stopped working again. So ignore my previous post.

After I set the cookiepath to "/" (available to entire domain) it worked yet again. So now my thinking is this... when you come to a page through a POST op, the cookie path is set by the POST page, and hence, all subsequent pages use the same cookiepath.

Whereas if you come to the page without a POST op, or some op that sets up the server vars, the initial cookiepath is not the same as the subsequent paths.

This still doesn't explain how I'm getting the language cookie and nothing else. Yes, you read that right, leaving the cookiepath at it's default, the only cookie persisting is the language cookie. When I set the path to "/", all cookies are persisting. If someone has an explanation to this, I would much appreciate it, and I could sleep a little better 8-)

I just hope there isn't a yet undiscovered side effect of setting the cookiepath to "/"... stay tuned...

-ufid

The cookie path is set at creation time of the cookie and not dependent on POST or GET.
If the cookiepath is blank, the created cookie is only valid in the current directory.

So if your loginscript resides in /login/login.php, the cookie is only valid in the dir called "login".
Not in /ubbthreads/ubbthreads.php for example...

Right, I realize that, and that's why I'm so bloody puzzled. Since my login script was/is in the same path as the rest of the ubb pages, namely, /ubbthreads/start_page.php for example.

That's why I couldn't figure out why it would only work if I went through a previous 'dummy' page. And my only reasoning is that I needed to be in the same directory/path on a previous page before going to the login page in the same directory and setting my cookie. It doesn't make any sense... but then again, that's why I'm puzzled. 8-)

I have a feeling that it has something to do with the language files being called and not having the cookie set properly to include thier paths.

As to the site wide setting, I think that most people use that as the default for thier sites. It is necessary for pretty much any design integration.

I think you'll some kind of step by step debugging is necessary. We can only guess, without knowing the code.