Osticket: Токен CSRF сломан при использовании обратного прокси

Ваш обратный прокси-сервер должен отправить X-Forwarded-For . Является ли?

Да, обратный прокси устанавливает X-Forwarded-For на правильный адрес. Клиент находится за NAT, поэтому Javascript потенциально может получить адрес RFC1918, если он получает привязанные адреса интерфейса (неясно, происходит ли это).

Можете ли вы проверить настройки файлов cookie между прокси-сервером (где запущен osTicket и клиентом)? Проверьте домен куки и путь куки возвращенного куки и убедитесь, что ни один из серверов между ними не сбрасывает куки или настройки куки.

Я проверю это, но вполне может быть, в чем проблема (внутренний домен хоста и домен как проксируемый сильно отличаются). Я обновлюсь через пару часов.

Я знаю, что этому посту больше года, но он появлялся несколько раз при попытке настроить обратный прокси-сервер с помощью osTicket. Я использую NginX в качестве обратного прокси (я знаю, не поддерживается и т. Д.) С некоторыми настройками, которые мне удалось передать с ошибкой «Недопустимый токен CSRF».

в моем блоке местоположения мне нужно было добавить несколько настроек заголовка:

 location / {
            proxy_set_header        Host            $host;
            proxy_set_header        X-Real-IP       $remote_addr;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass_header       Set-Cookie;
            proxy_pass <Backend osTicket location>;
        }

Pass_header был тем, что, казалось, заставляло его работать, но другие настройки гарантируют, что ваш сервер получит правильный IP-адрес. Я считаю, что вы также можете установить эти настройки на сервере или в блоке http, но это удовлетворило мои потребности.

@webbe, мы официально не поддерживаем nginx в качестве сервера для osTicket. Вы можете использовать все, что хотите для обратного прокси. Лично я предпочитаю HAProxy. Благодарим за размещение информации о конфигурации и рады, что ваша установка работает.