PHP cookie issue on redirect

[iseven]

I'm not exactly sure what the problem is but the cookies aren't available for subdomains. Is there any way around this, or is there a better way to set the cookies domain? Thanks!

<?php 
ini_set("session.cookie_domain", ".example.com"); 

// Set cookie and redirect when user change city 
if( isset($_POST['city']) && $_POST['city'] != '' ){ 
  $cookie_expire = time() + 50400; 
  setcookie('city', $_POST['city'], $cookie_expire, '/'); 

  header("Location: http://".$_POST["city"].".example.com"); 
  die(); 
} 

// Redirect if user selected default city 
if (isset($_COOKIE["city"])) { 
  $subdomain = array_shift(explode(".",$_SERVER['HTTP_HOST'])); 

  if ($_COOKIE["city"] != $subdomain) { 
    header("Location: http://".$_COOKIE["city"].".example.com"); 
    die(); 
  } 
}

[JD_Toims]

The domain that the cookie is available to. Setting the domain to 'www.example.com' will make the cookie available in the www subdomain and higher subdomains. Cookies available to a lower domain, such as 'example.com' will be available to higher subdomains, such as 'www.example.com'. Older browsers still implementing the deprecated » RFC 2109 may require a leading . to match all subdomains.

[php.net...]
setcookie('city',$_POST['city'],$cookie_expire,'/','.example.com');

[iseven]

Thanks JD_Toims but not working. It might be the place that I add the code was wrong. I have added the same code to 2 index.php pages which belong to main domain and sub-domain. Both domains are running the same program with the same script Is it correct?

[lucy24]

Does the problem happen in both directions? That is: cookie set in .example.com isn't available to sub.example.com AND cookie set in sub.example.com isn't available to .example.com? You may not actually need it to work both ways, but it's useful to know. I'm talking here about where the code physically executes, not about what it says.

[iseven]

You are right. Someone used this code for Drupal and should be the solution and way to go. I just have no luck to make it work.

Main Domain:
<?php
function YOUR_MODULE_NAME_init() {
 if(isset($_COOKIE['city'])) {
  header('Location: ' . base64_decode($_COOKIE['city']));
 }
}


Sub-domain
<?php
function YOUR_MODULE_NAME_init() {
 if(!isset($_COOKIE['city'])) {
  /*Your need to set cookie for your main domain, as well as for all your subdomains otherwise once a user visits another subdomain by typing the url directly in the address bar the cookie would be overwritten*/
  setcookie('city', base64_encode($_SERVER['HTTP_HOST']), time()+50400, '/', 'example.com');
  setcookie('city', base64_encode($_SERVER['HTTP_HOST']), time()+50400, '/', 'amsterdam.example.com');
  setcookie('city', base64_encode($_SERVER['HTTP_HOST']), time()+50400, '/', 'newyork.example.com');
  setcookie('city', base64_encode($_SERVER['HTTP_HOST']), time()+50400, '/', 'london.example.com');
 }
 else {
  header('Location: ' . base64_decode($_COOKIE['city']));
 }
}
?>

[lucy24]

Crikey, how convoluted. So the identical cookie has to be set on each subdomain separately? Why can't it just be set on the overall domain and be done with it? And how does the php know how many subdomains you've got? The quoted bit looks as if they're all hard-coded. Does it really come from a database?

[JD_Toims]

Well, I'm totally confused by what you're doing, iseven.

In your first example, you're using ini_set() to set the session.cookie_domain, but you're not using a session; you're just setting a cookie, so it has no effect.

Then in your first example you're setting the location as the city only, but in your next example you're using HTTP_HOST as the value with base64_decode($_COOKIE['city']) as the location for the city subdomain redirect.

Neither example has a protocol set, because HTTP_HOST doesn't contain a protocol, so when the browser receives the location header it's likely to stay at the same level on the same domain and request http://www.example.com/the-city.example.com or http://www.example.com/the-city depending on which is in the cookie.

Also, you're not checking any values to ensure they're "clean and untampered with", even though the cookie is stored on the end user's machine and sent back to your server -- It's not only "bad form", it's a security hole.

Then in the second example you have two different functions between the main domain and the subdomains, but on the subdomains in the second example you're setting a whole string of cookies even though they're all the same value -- If they're all the same and the example.com cookie is available to the subdomains then you don't need subdomain specific cookies, because the user won't be able to visit those subdomains anyway since you're redirecting to the city subdomain in the cookie when they land on the main or subdomain and have a cookie set.

---

I'm not sure how user friendly it's going to be to make it so no one can ever visit the main domain or a different city subdomain on the site until they either empty their cookies or the one you're setting expires, which is what it looks like you're doing, but that said:

Could you please explain what you're trying to do and which code you're actually using, because the two examples you've given "don't play well together" at all right now.

[iseven]

I just try to find the best solution to reach the goal. I need to redirect users to a visited sub-domain on his/her next visit to main domain. It doesn't matter whether the php, javascript or wildcard.

[lucy24]

That's what it looked like. Read the value of the "city" cookie, check whether a subdomain by that name exists, and redirect accordingly. Presumably the user can still manually select some other city, or start over with a clean slate ("city" = 0 or www. or unset or, heck, probably a dozen different approaches).

Did this start out as someone else's code?

[JD_Toims]

In answer to your question Lucy24, it's looking to me like it did.

---

iseven: my best advice is to take the time to learn the languages you're trying/wanting to work with -- I'm fairly certain there are members here who will help you through the learning process if you have a tough time or get stuck, but "coding for you" isn't something most of us are likely to do, often, imo, because we're "working on our own thing" or "working for someone who pays our bills."

As far as I'm concerned, helping someone else learn what I know is a contribution to the community that helps me when I get stuck and that's why I do it, but "just coding a solution for someone" when it's something they really don't seem to understand or even seem to care about learning how to code for themselves so it will work for them and they can keep not only making it work, but also improve upon it in the future *on their own* isn't something I'm personally interested in doing for two main reasons:

First: I get paid to code for a living -- Yes, I know that's shallow and greedy of me, but I spent a *ton* of time learning what I know and seo/coding custom solutions for websites is what I do to pay my bills.

Second: I learned more than a little bit from jdMorgan who was the mod in the Apache Forum for years, and he was absolutely right, imo, when he said, "Teaching a someone to fish is better than fishing for them." or something to that effect, so when someone "tries and gets stuck" and I have time, I try to help them out if I notice and can, but when someone says "just make this stuff I copied and pasted work for me", then it's not something I'm personally inclined to do.

[edited by: JD_Toims at 4:09 am (utc) on Dec 11, 2013]

[lucy24]

One of the stock answers next door in Apache is: First explain in English what you're trying to do. Then write code to get you there.

In this case, I think the overall scheme is:

User comes to site.
User selects a city and does stuff pertaining to that city.
User goes away, and returns on some later date.
Site remembers where he was last time, and sends him back there.
User continues where he left off, or backtracks to follow a different line of inquiry concerning some other city.

Is that about right? Now figure out your ideal user experience-- with all possible behaviors and variations-- and we'll see about coding to make the site behave the way you want.

[JD_Toims]

Awesome addition/interpretation of what I was saying/meaning Lucy24; Thanks!