SSL редирект

Чудеса просто :-) Решение просто нечто :-)

Держите нас в курсе!

Нет, правда, в чем решение?

Почему то срабатывает принцип плохиша :-(

Мне не помогли, и я не скажу. Хотя понимаю, что это как то неправильно...

Мне не помогли, и я не скажу.

Т.е. вам должны были помочь за 1:17 и 16 секунд, а раз уроды не сделали этого, то вы тоже ничего никому не скажете.

OOOK.

Нет, правда, в чем решение?

первое что может придтив голову, это очевидно, что причина в том что Apache не правильно редиректит. так как автор темы пишет нам: "Если перехожу из поисковика по ссылке, то попадаю только на главную".

ну значит наверно Apache-правила — которые указаны в сообщении — не правильные.. что тут ещё-то может быть?

а если так — то два варианта решения этой проблемы:

1. исправить неправельные Apache-правила — на правельные. :-)

2. сделать редирект через движёк сайта, а не заниматься сношением мозга с Apache.

------------------------------------------------------------

но так как автор этой темы не хочет говорить в чём решение проблемы, то мы можем предположить что это более сложный случай.

например, можно предположить, что Apache-правила *правильные*, но был другой некий косяк который всё равно всё портил.

(быть может автор темы практиковал какой-то шаманский SEO-хак, который в итоге всё испортил.. и теперь автору стыдно признаться в этом :))

кроме Apache-правил — автор темы нам не привёл ни чего другого в качестве материала для размышления, ...

... однако (и без всякого материала) я способен считать достаточно вероятной версией, что «постыдный» косяк всё-таки *был*, но автор темы не хочет называть этот косяк и поэтому пишет нам: "Мне не помогли, и я не скажу".

так как у других людей не возникает ни каких проблем с редиректом HTTP->HTTPS — то я склонен полагать что эта форумная тема достаточно бесполезная, и что автор темы не сообщит нам ни чего особо важного.. даже если признается в чём был его косяк :-)

Is Russian your native language?

правельные
движёк
ни каких
не правильно

то мы можем предположить что это более сложный случай.
автор темы не сообщит нам ни чего особо важного

Это очевидно, что косяк его собственный. И ответ его нафиг никому не нужен, но меня удивил сам подход.

Is Russian your native language?

да.. но язык этот очень сложный! даже учитывая, что native :-)

а на non-native я говорю\пишу ещё хуже :-( [так как слишком много различных времён и форм глаголов, и фиг пойми их все!]

Это очевидно, что косяк его собственный. И ответ его нафиг никому не нужен, но меня удивил сам подход.

но на самом деле — всё равно — достаточно любопыто узнать что же за косяк.. даже подписался на тему :) ..

Ответ я дам - не перживай. Я не настолько плохиш :-)

Апач правила не менялись :-) Так что стыдиться тут не чего :-)

Ну ты и грязный извращенец. Делай так:

<VirtualHost 193.124.3.1:80>
    ServerAdmin webmaster@demos.ru
    ServerName mail.demos.ru

    Redirect permanent / https://mail.demos.ru/
</VirtualHost>
<VirtualHost 193.124.3.1:443>
    SSLEngine on

    ServerAdmin webmaster@demos.ru
    ServerName mail.demos.ru
    ...
    ...
</VirtualHost>

Любые совпадения айпишников и айпи-адресов считать случайными =)

Все это прекрасно и я с удовольствием бы так сделал, но доменов много и все они используют разные IP адреса.

Как быть в этом случае?

Ответ я дам - не перживай.

Так давай, а не ломай тут комедию.

Да ответ банально просто - из конца файла я эти правила передвинул в начало списка - и все.

Нашел инет в инете - видимо, не только у меня были такие проблемы.

Ну и тут теперь поиском будет искаться.

Важный нюанс...

У меня ещё есть красивое решение для nginx, если надо перенаправлять только часть запросов.

Да ответ банально просто - из конца файла я эти правила передвинул в начало списка - и все.

это довольно странно, ведь ты в правилах указал флаг "[L]"..

а флаг "[L]" — как-бы тебе должен был намекать что это правило НЕ должно быть последним :-)

как же так могло получиться? :-)

У меня ещё есть красивое решение для nginx, если надо перенаправлять только часть запросов.

красивое правило. да!

Nginx вообще норм придумали всё. (почти всё)

единстенное (но ФАТАЛЬНО!) что меня раздражает в Nginx — это его НЕумение запускать FastCGI-приложение и передаваь ему socket внутри нулевого файлового дескриптора [а быть может даже и вообще оно не умеет запускать FastCGI-приложение, не говоря об socket в нулевом дескрипторе].

вот как же так — такие умные ребята изобретали этот Nginx, а в итоге сделали такую недоработку :-) ..

а тем временем — последняя версия Apache поумолчанию обрабатывает сетевые соединения в event-режиме (умела и раньше, но делало это НЕ поумолчанию)..

что меня раздражает в Nginx — это его НЕумение запускать FastCGI-приложение

Do one thing and do it right. ;)

Fast-CGI к http как-бы мало относится. Мало ли что на сокете слушать может? KISS в общем.

Ответ же очевиден, не?

Мало ли что на сокете слушать может?

можешь, пожалуйста, рассписать эту мысль подробнее? не смог её распарсить :-)..

ты имеешь ввиду что "вдруг некоторая программа имеет экспортировать функцию FastCGI, но при этом не является *только_лишь* FastCGI-приложением, и выполняет другие смежные функции..."..

...или что-то другое?

KISS в общем.

некоторые люди (я вобщем-то так не делаю ни когда.. но всё равно находятся достаточно много их) — заворачивают Apache (бекэнд-сервер) под Nginx (фронтэнд-сервер).

и хочу сказать что такая ситуация — мне кажется явно не KISS :-)

Возмём мой блог. Он писан на Go, слушает fcgi. Как его запустить из apache?

Или мою работу. Там пишут на python/django. Как его засунуть в apache?

Я к тому, что вариантов слушать на fcgi много, а запускать эти приложения — или монстр-apache выйдет, или kiss-nginx, который про это вообще не чешится.

Возмём мой блог. Он писан на Go, слушает fcgi. Как его запустить из apache?

должен быть (наверно?) какой-то модуль на GO, который умеет слушать FastCGI-сокет из нулевого дескриптора.

но я с Go не знаком.. так что ответить на вопрос — не смогу :-)

Или мою работу. Там пишут на python/django. Как его засунуть в apache?

а для python — всё просто — существует всего-лишь пара~тройка строчек которая нужна в Apache-конфиге:

# ... ... ...
LoadModule fcgid_module blahblahblabhla/mod_fcgid.so
# ... ... ...
AddHandler fcgid-script .fcgi
# ... ... ...

вот и всё! далее Апач будет считать любой *.fcgi-файл как FastCGI-приложением, а следовательно: запускать его и передавать ему socket внутри нулевого дескриптора .

а на стороне python — используем flipflop ( https://pypi.python.org/pypi/flipflop ) . засовываем соответвующий файл в каталог в котором разрешён «Options +ExecCGI».

вот и всё .. :-) где тут монструозность-то?

помоему всё минималистично и красиво :-) ..

...в Nginx так минималистично врядли получится. ведь придётся (в случае Nginx) придумывать свою собственную схему для старта всех FastCGI-демонов. дополнительно ещё и — продумывать систему безопасности для хранения socket-файлов

Там всё чуть-чуть сложнее. ;) Просто интерпретировать *.fcgi не выйдет. Каждой app нужно ещё инициализироваться, ещё там что-то. Смежные таски.

Может быть и можно, но зачем? Тем более

придумывать свою собственную схему для старта

supervisord, upstart, whatever, you chooose it — решается тоже без проблем.

Я к тому, что вариантов слушать на fcgi много, а запускать эти приложения — или монстр-apache выйдет

ты имеешь ввыду — что в Apache раелизовать слишком много альтернативных вариантов по запуску этих всех решений?

в том смысле что разработчики «перестарались»? :-)

Каждой app нужно ещё инициализироваться, ещё там что-то. Смежные таски.

если только такая ситуция — то да :-) — врядли Apache поймёт почему всё подзависло при FCGI-запуске :-)

а если ситуация когда всё состояние хранится только внутри базы данных — то наверно не так уж и много нужно сделать всяких разных инициализаций

ну вообщем да. я понимаю в какую сторону ты клониш.

о том, что — серъёзный (большой) web-проект может зависит от кучи всего разного, от кучи разных демонов..

и на этом фоне меркнет запуск именно FCGI-демона :-)

и в этом смысле — создатели Nginx решили просто НЕ реализовывать запуск FCGI-демонов (оставили это дело на усмотрение web-разработчика)..

это интересная позиция! да! но вот эта позиция мне как раз и не нравится, потому что ведь бывают и НЕ большие web-проекты. (а не только большие :))

Честно признаться, не хочу особенно спорить. Да и offtopic это.

Apache всем хорош (был). Но это комбайн. Чего в нём только нет. А чего надо нет. ;)

Вполне хорошее решение для LAMP. Но даже и там я перешёл уже давно на связку nginx + fpm-php.

И скорее даже протсо по-тому, что nginx более удобный и гибкий в настройке.

А запустить upstream для него — это не проблема.

это интересная позиция! да! но вот эта позиция мне как раз и не нравится

Дело вкуса. Какая разница два у тебе таска в init.d или один?

Зато это гораздо упрощает (и обесопасивает) httpd-daemon, который при этом ещё и справляется со своей задачей гораздо лучше.

PS: на маленьком vhost с nginx+django я справлялся с нагрузкой от телевидиния — а это дофига rps. (Общая нагрузка низкая, но как нагрянут — ховайся!)

и обесопасивает

говорить о безопасности — можно только лишь в случае когда socket-файл доступен не более чем двум программам (на сервере): nginx и fcgi-демону.

а зачастую простая схема (простая схема обеспечения доступности socket-файлов) — предполагает что socket-файлы доступны аж для целой группе пользователей (например нескольким разным FCGI-демонам, которые не связаны друг с другом, но они оказались на одном сервере).

если какая-то другая программа (например взломанная) получила доступ к чужому socket-файлу — то она сможет напрямую посылать некорректные (фльшивые) запросы к чужому FCGI-демону и чёрт знает к чему это может привести. :-)

не сказать что бы это прям реально способно привести к взлому.. но всё же — при определнных (других) обстоятельствах этим можно было бы воспользоваться злонамеренно! :-)

в случае Apache — Апач не только опеспечивает запуск fcgi-приложения, но и сам Апач обеспечивает безопасность socket-файла. fcgi-приложение можно запускать от разнообразных прав (mod_suexec) , но при этом всегда fcgi-приложение будет иметь доступ к socket ! а другие программы доступ иметь не будут (root не в счёт, конечно)!

а в случае Nginx так как мы сами запускаем fcgi-демон — то и мысами должны придумать хитрый механизм по которому ни кто другой не сможет доступчаться до socket-файла.

и я бы не сказал бы что это всё очень сложно (в случае Nginx самому всё это продумывать) — но просто мне кажется что такого рода вещи должны быть чуток более тривиальными :-) ...

и конечно проблем-и-гемороя будет минимум (ды вообще не будет!) если только один FCGI-демон у нас на одном сервере. :-)

на маленьком vhost с nginx+django я справлялся с нагрузкой от телевидиния — а это дофига rps. (Общая нагрузка низкая, но как нагрянут — ховайся!)

да. эт похвально разумеется!

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

На каждый виртуальный хост с SSL делаешь по виртуальному хосту без SSL. Если их там у тебя сотни, напиши скрипт на баше/перле/питоне, чтобы он тебе нагенерил.

Все это прекрасно и я с удовольствием бы так сделал, но доменов много > и все они используют разные IP адреса.

Как быть в этом случае?

На каждый виртуальный хост с SSL делаешь по виртуальному хосту без SSL. Если их там у тебя сотни, напиши скрипт на баше/перле/питоне, чтобы он тебе нагенерил.

а если Apache — то быть может — можно можно ещё и воспользоваться <Macro> (mod_macro)

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Если пороешься в моём блоге — у меня там ещё парочку красивых решений с новыми плюшками. В частности mime-expires и гибкий роутинг на несколько бекендов.

Ага, с удовольствием гляну.