Сookie session key

Браузер никак не понимает, для него все куки одинаковые, он не знает что в них. Куки это набор параметр=>значение, привязанные к домену (или к домену и его субдоменам) и имеющие время устаревания, не более того. И параметр и значение это текст, как его интерпретировать - проблема приложения.

Куки может быть более одного, и устанавливать их может кто угодно, имеющий доступ к HTTP Response. Сначала например может установить твое приложение, потом что-то еще добавить или даже заменить веб-сервер. Если есть по пути прокси - и та значит может что-то еще туда насрать. Тащемта все как и с любым другим HTTP Response Header. Просто так решили, что все то что приходит в определенном формате в HTTP Response Header с именем Set-Cookie, считаем куки и при следующем запросе на тот же домен все эти куки собираем в одну строку через точку с запятой и добавляем к запросу в виде HTTP Request Header с именем Cookie.

Если не понятно, как это работает, посмотри трафик вирешарком, все станет ясно.

Ну это понятно, и немного таки неясно. Set-Cookie: Name=key; дата годности path=/. Но сам session key особенно, если он рэндомный как-то же выставляется, и его может ставить как приложение(php, perl...), как прокси, так и сам веб-сервер. (по сути все что на пути до веб-сервера, включая его самого). Но однако в одном случае браузер его принимает, а в другом нет, и получается что session key пустой.

для начала надо понять что такое сессия. Сессия - это некий объект, имеющий идентификатор, и содержащий какие-то данные. Фактически сессия нужна для того, чтобы вместо десятка разных настроек для каждой из которой понадобится свой куки, передать на клиент один этот идентификатор. При HTTP-ответе по этму идентификатору твое приложение лезет в базу или в файловую систему и пытается оттуда вытащить эти данные. Цена этому - один лишний sql-запрос (или обращение к файловой системе) при ответе и один при запросе. Все.

Соответственно браузер ничего про сессию не знает, к нему пришло что-то вроде Set-Cookie:sessionid=huypizdaff123213. Не принять он этого не может, потому что сессия ничем не отличается от других куки. Если не работает - значит либо сервер не шлет куки с сессией на клиент, либо шлет, но с неправильной датой expired, либо шлет, но не для того домена, либо при запросе/ответе этот куки кто-то по пути отрезает. Клиент здесь в любом случае ни при чем.

Посмотри вирешарком что там ходит от сервера к клиенту и обратно.

Я посмотрю, чуть попозже, чисто чтобы получше разобраться. Но я тем же curl вижу, что если к сайту #1 устанавливается cookie c session key, то второй просто отдает 403ю. Потому-что там нет session key у браузера при соединении, но конфигурация одинаковая. О чем и сообщает веб-сервер в логах Session key in not defined.

А еще есть такой интересный пример если для vhost'а первого вырезать cookie, которое устанавливает приложение (сама CMS) и поставить точно такую же веб-сервером, то почему-то сайт не даст авторизоваться, хотя по сути cookie одна и таже. Идей почему так происходит пока нет.

Но я тем же curl вижу, что если к сайту #1 устанавливается cookie c session key, то второй просто отдает 403ю. Потому-что там нет session key у браузера при соединении, но конфигурация одинаковая. О чем и сообщает веб-сервер в логах Session key in not defined.

Так в чем проблема? Приложение не ставит куку (при логине)?

Уже нет проблем, перешел на другое решение.