problem with cookies being set, but rejected

[awesome_aims]

Hey, I recently created a basic login script for a new site I'm working on that uses cookies. My problem is that on everyone who tested it, who has a newer computer, with a newer version of XP has the cookie rejected. heres the main part

// if they chose to be rembered:
if($remem == "yes") {	
  //sets the cookie for 1 year:
  if(setcookie("cookiename", $uname, time()+3600*24*7*52)) {
    $yesorno = "Login complete";
   else {
    $yesorno = "Login Failed";
  }
// if they chose a regular login:
} else {
  // sets the cookie for 6 hours:
  if(setcookie("cookiename", $uname, time()+3600*6)) {
    $yesorno = "Login complete";
  } else {
    $yesorno = "Login Failed";
  }
}

with the people that have the newer computers, echo $yesorno; is displaying "Login Complete", but its not actually setting the cookie. (Note: if i add or subtract ANY attributes from setcookie(), it flatout doesnt work period, for anyone)
Will it be possible to get it to work for pretty much everyone? would I get a different result if I used sessions? if so, what would i substitute the above code with to use sessions, and how would I call them?

[bradgrafelman]

Have you tried using a complete [man]setcookie/man call?

setcookie('cookiename', $uname, time()+3600*6, '/', '.mysite.com', 0);

[awesome_aims]

nope it's still not working for newer XP and IE versions. Can anyone help mee on this, is anyone else having this problem? Since sessions use cookies, would I have same problem if I changed it? Thanks.

[bradgrafelman]

Can you by chance give us a link? I'd like to see this cookie being set...

[awesome_aims]

ok, here
www.aimpasswordstealer.com
dont be scared by the name, its for search engine ranking purposes
login with
Username: testingbitch
Password: tester
(feel free to use the features with that username also)

[bradgrafelman]

Here's what your server sent back to me when I POST'd my login data:

Set-Cookie: apsusname=bradgrafelman; expires=Sunday, 11-Mar-07 03:52:59 GMT; path=/; domain=.awesomeaims.com

On subsequent pages, try doing a print_r($_COOKIE); and see if 'apsusname' shows up. If not.. I'm at a loss as to why that would be. Seems fine to me.

[Roger_Ramjet]

The problem with IE will be down to their Privacy Settings in Internet Options. Default in IE 6 is for 'medium' privacy and that means a lot of blocked cookies. You can use javascript to test if cookies are allowed and alter the settings if not - and do it silently. Trouble is that now M$ are recomending to people to turn js off in IE. Trying to plug all the disease vectors they built into the piece of crap they made.

[bradgrafelman]

Works fine in FireFox.

Tell IE users to get a real browser. 😉

EDIT: What MIGHT possibly be happening is that IE is blocking the cookie from being sent back to your server because of the frames. The main page (not the iframe) is on a different domain that the login page, so perhaps IE thinks that by going to aimpasswordstealer.com and having an element on the page try to set a cookie for awesomeaims.com is a cross-site scripting attack.

Does that make sense to anyone else?

[Roger_Ramjet]

Yes, and that is what is happening. IE blocks 3rd party cookies if they contain any identifiable info, which means almost all cookies cos what else is the point of them except to track you. Users will have to lower the privacy level or explicitly accept them for your domain - yet another IE hack to code for.

[bradgrafelman]

If you got rid of the frame altogether, I'm betting this would work fine (assuming users don't have cookies disabled altogether).

[awesome_aims]

ok thanks, I know that's the problem now. In order to get rid of the iframe I must connect with the MySQL from a different server, if tried everything and it's still not letting me, through cpanel I allowed the host to access the mysql, and I'm trying to connect like this:
mysql_connect("11.111.1.111", "username", "password");
it's returning the error:
"Warning: mysql_connect(): Lost connection to MySQL server during query in /home/awesomea/public_html/csp.php on line 6"
iv'e also tried connecting to ports: 11.111.1.111:3306
and its returning the same error

[bradgrafelman]

Firewall/router/IPCop/etc. blocking the port, perhaps?

[viza]

awesome_aims wrote:

ok thanks, I know that's the problem now. In order to get rid of the iframe I must connect with the MySQL from a different server, if tried everything and it's still not letting me, through cpanel I allowed the host to access the mysql, and I'm trying to connect like this:
mysql_connect("11.111.1.111", "username", "password");
it's returning the error:
"Warning: mysql_connect(): Lost connection to MySQL server during query in /home/awesomea/public_html/csp.php on line 6"
iv'e also tried connecting to ports: 11.111.1.111:3306
and its returning the same error

You need to enable network connections on mysql. Be aware that you will then need to specify connection strings for all your stuff running locally once you set this up, unless you set the connection up in php.ini, which in a hosted environment is very insecure.

On linux, in /etc/my.cnf, you change the line that reads:
socket=/var/lib/mysql/mysql.sock
to
socket=3306

which is the standard mysql network port. You should then ensure that this port is blocked from any subnets but the subnet where your web servers are, with IPTABLES. You should then add users to mysql and be very specific about which IP's they are allowed to connect from.

In fact, if you don't add users to mysql and specify the allowed IP's, they won't even be able to connect at all. I'll leave the particulars of this stuff to the MySQL and IPTABLE's manuals/documentation. As always some effort expended in reading the docs and learning how it works will pay dividends.

Network enabling mysql can be very (VERY) dangerous if done improperly so make sure you do it in a secure manner with the help of a competent network engineer and system administrator/dba.

-Viz