Set cookie domain

[ForestMars]

I just noticed that sessions are not working across www and the apex (aka naked) domain.

So I can be logged into nyccamp.org at the same time I am logged out of www.nyccamp.org.

We need to add a $cookie_domain to our settings.php file to fix this.

[likewhoa]

all done.

[esod]

Hi Guys, I pulled live's db into test and merged in this pr to test. Now test is not working right. I can log in, but I'm no longer a site admin although the database says so.

The menu is no longer working right.

I don't know if these bugs are related to the cookie domain, but we shouldn't push anything more to live until we've sorted the issues out.

[esod]

Pantheon doesn't use our settings.php and settings.php hasn't been in the repo for a while.

[likewhoa]

ugh, then we need nginx rewrite for www.

[mirie]

Pantheon does use our settings.php and it is in the repo ;). Just want to clarify this part because there's a little confusion here about this.

In terms of the login and the www problem, I'm not 100% sure, but I think we can just remove this line from settings.php:

$cookie_domain = '.nyccamp.org';

and add this to the default settings.php (at the end):

if (isset($_SERVER['PANTHEON_ENVIRONMENT']) && $_SERVER['PANTHEON_ENVIRONMENT'] === 'live') {
  if ($_SERVER['HTTP_HOST'] == 'nyccamp.org' || $_SERVER['HTTP_HOST'] == 'live-nyccamp2014.gotpantheon.com') {
    header('HTTP/1.0 301 Moved Permanently'); 
    header('Location: http://www.nyccamp.org'. $_SERVER['REQUEST_URI']); 
    exit();
  }
}

[esod]

~/kalabox/www/nyccamp2014 (master)-2$ git pull upstream master
From github.com:NYC-Camp/website

• branch master -> FETCH_HEAD
  Updating 8b66c29..4fc8f70
  error: Your local changes to the following files would be overwritten by merge:
  sites/default/settings.php
  Please, commit your changes or stash them before you can merge.
  Aborting

git status does not show sites/default/settings.php as modified.

[esod]

And if you're not using the kalabox, getting this merge in is going to remove all their settings.

[ForestMars]

Um, we need to be very careful here guys. Pantheon is very brittle when it comes to settings.php. One wrong commit and BOOM your site is toast.

As a reminder, no one should ever, EVER be merging their own PR and pulling code to Live. (Not to mention if anyone blows up Dev that way, we cannot just recover it, that's a support request to Pantheon.)

However, one thing I need to ask is why we are having to twist ourselves through all these contortions. My gut is telling me that we have a bug/mistake that we are only making worse, and it all seems to revolve around the session/propose path alias, which I now understand someone used a redirect for instead of a Drupal alias.

And I've also just noticed that our node/add/* path is hacked up. So instead of the correct Drupal behavior for anonymous users, it's now returning a 403. That is wrong. Drupal does not return 403's to anonymous users for the node/add/* path. That looks like something that's been broken on the nyccamp site.

So before we go too far down the path of compounding earlier mistakes, I'd suggest we clean up our node/add/* path, so that it's working correctly in Drupal again, remove any complicated redirects of custom jiggery, and use a standard Drupal alias.

[ForestMars]

Also, good catch Eric on comment #3, and a gentle reminder to everyone to use PR's.

[esod]

Will someone merge this in? #178 It's a blocker.

cod alpha-1.5 oob has OG 2.5 and it has the node/add bug. We don't. I guess you're surfacing whatever steps we took to resolve it. But that's a different discussion.

I want to check if the change to field_room_assigment (#170) I can't do that until my pull request is merged in. The pull request will only go to dev which. like test but not live, is also busted.

[esod]

There's a comment in the screen shot.

https://www.evernote.com/shard/s239/sh/bd359573-7216-4160-b48f-d96c4f778fda/cfcd7f09d6c3a5ca2101336909b14aef

[ForestMars]

No, I don't think so. In fact, it looks like it's set up correctly.

We should only have one A record per server for the domain. So if we have an A for the apex we don't have an A for www, and vice versa.

My recommendation is that we have an A record for the apex domain (nyccamp.org) and a CNAME for www.nyccamp.org, which is exactly what it looks like we have.

I don't actually think the problem is in DNS. Since we did not have this problem last year, evidence points to something we've done, or changed since then, and not anything in the zone file.

[ForestMars]

I think the problem is that the fix for the node/add bug is wrong?

That is, the correct fix is that anonymous users going to node/add* should be redirected to /user.

However, on nyccamp.org they instead get an access denied, which is wrong.

Where did we add that redirect to address the bug in OG 2.5? (That removes the redirect to /user and gives anonymous users apparent access to node/add?

[esod]

So the CNAME with www Points to @ is okay. cool.

dunno about the node/add stuff. I guess we'll have to look at that again.

[ForestMars]

y, domains are fine, we did something in code to mess this up.

I'm a little concerned that now we have a pull request to add login destination module, without knowing what the underlying problem is. That's just adding more layers of complexity / obfuscation.

We need to simplify, not complicate. And determine what the exact problem is.

And also fix node/add/* so it redirects to /user, not a 403.

[likewhoa]

Closing this but I still think that redirecting from http://nyccamp.org to http://www.nyccamp.org is lame and I plan on reversing this redirect after the camp finishes.

[ForestMars]

totes lame. @fixme on 4/14/14