[РЕШЕНО] Ошибки при работе frontend+backend сессии

Главные вкладки

Аватар пользователя XATRIX XATRIX 11 октября 2012 в 0:24

Всем доброго вечера, случилась у меня такая проблема. Решил перенести сайт на другой сервер. А именно кластер. Тоесть мы имеем:

1 frontend (nginx (proxy)) <---> 2 backend (nginx + php-fpm + mysql + mail....)

Проблема заключается в том, что залогиниться на сайт на новом сервер возможно только с двух - трех попыток, разлогиться нельзя никоим образом. У нас есть модуль отвечающий за работу почты, так вот там должен подгружаться TinyMCE, если некоторое время не дергать браузер, то потом, при попытке открыть "Написать письмо" просто напросто пишет ошибку "The requested page "/node/110152/edit" could not be found." Хотя через какое-то время , или попыток разлогинивания - начинается нормально открываться...

Вопрос мой возможно окажется немножко оффтопом, но прошу помочь мне посильно: Как правильно нужно настроить nginx на фронтенде и на бекенде чтобы Drupal корректно работал с сессиями ?
___________________________________________________________________________________

Ниже привожу мои конфиги с серверов:
1. Фронтэнд:

server {
server_name www.somedomain.ua;
access_log /var/log/nginx/somedomain.ua.access_log;
error_log /var/log/nginx/somedomain.ua.error_log;

proxy_buffering on;
proxy_set_header X-Real-IP $remote_addr;

location / {
proxy_pass http://main;
proxy_set_header Host $host;
#proxy_cache my-cache;
№proxy_cache_valid 200;
}

location ~ \.php$ {
proxy_pass http://main;
proxy_set_header Host $host;

#proxy_cache my-cache;
№proxy_cache_valid 200;
}
}

2. Бекенды:
server {
server_name somedomain.ua;
root /mnt/www/somedomain.ua; ## <-- Your only path reference.

access_log /var/log/nginx/somedomain.ua.access_log main;
error_log /var/log/nginx/somedomain.ua.error_log;

location = /favicon.ico {
log_not_found off;
access_log off;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

# This matters if you use drush
location = /backup {
deny all;
}

# Very rarely should these ever be accessed outside of your lan
location ~* \.(txt|log)$ {
allow 192.168.1.0/24;
deny all;
}

location ~ \..*/.*\.php$ {
return 403;
}

location / {
# This is cool because no php is touched for static content
try_files $uri rewrite;
#proxy_pass http://somedomain.ua;
#proxy_cache my-cache;
#proxy_cache_valid 200 302 60m;
#proxy_cache_valid 404 1m;
}

location rewrite {
# Some modules enforce no slash (/) at the end of the URL
# Else this rewrite block wouldn't be needed (GlobalRedirect)
rewrite ^/(.*)$ /index.php?q=$1;
}

location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
#NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;

#fastcgi_pass_header Cookie;
#fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
#fastcgi_cache_key "$server_addr:$server_port:$request_uri|$cookie_phpsessid";
#fastcgi_cache fastcgi_cache;
#fastcgi_temp_path /mnt/cache/tmp 1 2;
#fastcgi_cache_use_stale updating error timeout invalid_header http_500;
#fastcgi_cache_valid 20s;
#fastcgi_cache_valid any 20s; #For any queries cache
}

# Fighting with ImageCache? This little gem is amazing.
location ~ ^/sites/.*/files/imagecache/ {
try_files $uri rewrite;
}
# Catch image styles for D7 too.
location ~ ^/sites/.*/files/styles/ {
try_files $uri rewrite;
}

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires max;
log_not_found off;
}
}

Комментарии

Аватар пользователя XATRIX XATRIX 12 октября 2012 в 10:53

не совсем, я интересовался на freenod-е, мне объяснили это так, как якобы Drupal хранит сессии php в базе данных а не в файлах на диске (к примеру в /var/lib/php/session). Соответственно как же тогда веб-сервер будет проксировать это все ? У меня просто напросто сбивается авторизация при переходе по другим ссылкам, а разлогиниться вообще не получается...

Аватар пользователя XATRIX XATRIX 12 октября 2012 в 12:35

Дело в том что в ходе экспериментов выяснилось, что если работать с бекендом напрямую - то ошибок с авторизацией не возникает. Все работает как часики.
Если подключаем фронтенд, тоесть промежуточное звено, проблема снова появляется.
Никакого сжатия, кеширование на фронтенде "пока" не производится... Сессионую куку я отследил, она передается и через фронтенд, но почему-то после первого залогинивания, нужно принудительно обновить страничку, тогда ты уже оказываешься в системе.

Аватар пользователя XATRIX XATRIX 12 октября 2012 в 18:38

Сделал вывод что для нормальной работы друпала надо юзать X-Forward-For переменную на стороне nginx-а, для того чтобы корректно отслеживать адреса проксируемые фронтендом. Только толку мне это особо не дало, по прежнему вопрос открыт...

Аватар пользователя divined divined 15 октября 2012 в 10:04

Теперь попробуйте любой другой движок на созданной вами системе. Увидите что они тоже не логинятся и может тогда поймете что форумом все-таки ошиблись )

Аватар пользователя XATRIX XATRIX 28 октября 2012 в 14:37

Вопрос был решен, изменением конфигурации реверс-прокси фронтенда.

Не помню точно, то что-то из этих параметров:
client_body_timeout 60;
client_header_timeout 60;
# keepalive_timeout 60 60;
keepalive_timeout 3;
send_timeout 60;

В частности при получении главной странички она приходила у меня с заголовками max-age=86000 - соответственно браузер её кешировал.

После игры с этими параметрами хедеры стали приходить такие:

Request Headers
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Cache-Control   no-cache
Connection      keep-alive
Response Headers
Cache-Control   no-cache, must-revalidate, post-check=0, pre-check=0
Connection      keep-alive
Content-Encoding        gzip
Content-Language        ru

Как видим при получении правильных Cache-Control хедеров - браузер не кеширует страничку и авторизация работает нормально.