Apache в качестве обратного прокси-сервера с аутентификацией, передаваемой изнутри - PullRequest
Новая
       33

Apache в качестве обратного прокси-сервера с аутентификацией, передаваемой изнутри

0 голосов
/ 04 ноября 2011

У нас есть приложение, работающее на Weblogic 10.3, с аутентификацией, предоставляемой в самом приложении. Мы хотим разместить Weblogic за сервером Apache. Идея состоит в том, что у нас будет публичный контент на сервере Apache, и приложение будет доступно через обратный прокси-сервер. Это в значительной степени очень стандартно. Проблема заключается в том, что на сервере Apache имеется некоторое содержимое, доступ к которому возможен только в том случае, если пользователь вошел в приложение. Таким образом, сервер Apache будет обслуживать три типа содержимого на разных URI:

  • / -> будет содержать общедоступную информацию и будет сервером Apache
  • / myApp -> Apache будет перенаправлен на веб-сайт, стоящий за
  • / private -> будет содержать приватную статическую информацию. Это должно быть доступно только в том случае, если пользователь ранее успешно вошел в myApp.

Мой вопрос (я новичок в Apache), если это возможно. Моя идея состоит в том, что приложение может поместить cookie в ответы, указывающие, вошел ли пользователь в приложение, и что Apache проверит этот cookie, когда пользователь попытается получить доступ к /private.

.

Есть мысли?

1 Ответ

4 голосов
/ 04 ноября 2011

Публичная информация / не проблема, это просто. Использование ProxyPass или ProxyPassMatch для обратного прокси-сервера "/ myApp" на вашем внутреннем сервере Weblogic также просто. Возможно, вам придется использовать несколько других параметров, чтобы убедиться, что домены прокси-сервера и cookie-файлы настроены правильно. Но настройка статической защищенной информации в "/ private" будет немного сложнее.

1) Вы можете проверить наличие cookie, установленного myApp, используя mod_rewrite, что-то вроде этого: 

RewriteCond %{HTTP_COOKIE} !the_name_of_the_auth_cookie
RewriteRule ^private - [F,L]

Проблема с проверкой файлов cookie с помощью чего-то подобного заключается в том, что невозможно проверить, является ли файл cookie действительным сеансом. Люди могут произвольно создать cookie с таким именем и иметь доступ к данным в / private.

2) Вы можете настроить его так, чтобы к чему-либо в "/ private" обращались, запрос переписывался в скрипт php или что-то, что может проверять cookie, чтобы убедиться, что это действительный сеанс cookie, затем откройте запрошенную страницу. Что-то вроде: 

RewriteRule ^private/(.*)$ /cookie_check.php?file=$1  [L]

Так что, когда кто-то обращается, например, к «/private/reports.pdf», он внутренне перенаправляется на «/cookie_check.php?file=reports.pdf», и этот скрипт php может получить доступ ко всему, что ему нужно для проверки файла cookie, который имеет / myApp. Если файл cookie является допустимым сеансом, прочитайте файл «reports.pdf» и отправьте его в браузер, в противном случае верните FORBIDDEN.

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

3) Если вы не можете запустить php или какие-либо другие сценарии, или cookie не может быть проверен (например, с помощью поиска в базе данных session_id или чего-то подобного), то вам придется прокси из в рамках WebLogic. Это было бы в большей степени той же базовой идеей, что и доступ к "/ private" через "cookie_check.php", за исключением того, что это приложение на сервере WebLogic. Как и / myApp, вам нужно настроить обратный прокси для доступа к нему, затем это приложение получит запрос (который был внутренне переписан из "/ private / some_file"), проверит правильность куки, прочитайте файл "some_file" На сервере APACHE, затем отправьте его в браузер или отправьте ЗАПРЕЩЕНО. Это общая идея: 

ProxyPass /CheckCookie http://internal_server/check_cookie_app

RewriteCond %{REMOTE_HOST} !internal_server
RewriteRule ^private/(.*)$ /CheckCookie?file=$1 [L]

Это условие перенаправляет все запросы на "/ private", которые не исходили от "internal_server" через приложение / CheckCookie, и, так как приложение работает на "internal_server", оно может обращаться к файлам в "/ private" очень хорошо , Это своего рода обходной способ сделать это, но если действительность сессионных куки-файлов, выпущенных / myApp, можно проверить только на сервере WebLogic, вам придется перенаправлять запросы туда-обратно или что-то подобное.

...