Как сделать доступ к файлу по определеному url и нужно ли это?

Question

[Андрей Хохлов]

Сервер nginx (frontend) + apache (backend).
Мультиязычный Wordpress (плагин Polylang).

Для авторизации используется api другого сайта, которое в случае если пользователь правильно ввёл логин-пароль возвращает токен для дальнейшей авторизации пользователя.

То есть:
example.com > example.ru > ввод логина/пароля, если ок то > example.com + токен

Сейчас сделал криво.
Создано 2 страницы на которые апи возвращает токен для дальнейшей авторизации:
example.com/ru/auth-ru/
example.com/en/auth-en/
а в самом шаблоне страницы никакого вывода, только действия по авторизации и редирект на страницу скоторой человек нажал "войти".

Это немного убивает логику: шаблоны страниц лежат в папке pages и среди них файл исключительно с логикой, да и в админке зачем-то создана страница которой по сути не существует.

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

В котором загрузить wordpress (чтобы использовать функции)

require_once( $_SERVER['DOCUMENT_ROOT'] . '/wp-load.php' );

Сделать всё что нужно и переадресовать человека на страницу с которой он начал авторизацию.

Сейчас если допустим положить его в корень сайта и обратиться example.com/auth.php то получу страницу 404

Правильный ли это подход вообще и как прописать (подозреваю что в .htaccess) правила для такого url'а?

Answer 1

[Игорь Воротнёв]

Ответ уже как бы есть, я только не могу понять, зачем городить сторонние файлы, делать редиректы и тд. Есть же такая удобна штука как хуки. Например - init, template_redirect, template_include. Вместо целого файла регистрируете query_var, можно даже rewtie_rule свой (example.com/auth/). При попадании на этот урл в хуке init или template_include стартуете авторизованную сессию, если есть токен, делаете что надо (например сверяете токен с таковым в таблице wp_usermeta), дальше отправляете на нужную страницу (откуда начали авторизацию). Гибкость фантастическая. И все - родные фичи WP, а не костыли. Да, это более advanced topic, чем просто сторонний файлик, но и более гибкий в результате, более надежный и безопасный. Вот в вашем случае, например, а что, если токен левый отправить? Проверки есть? Какая-нибудь API key pair есть? Так чтобы один ключик на том сервисе где логинитесь, а второй - на самом сайте. Понятно, что вы детально не раскрыли механизм авторизации, но со стороны здесь просматривается не очень надежное место.

Comments

[Андрей Хохлов]

Игорь Воротнёв спасибо за ответ! Много времени с тех пор прошло, но проект по прежнему у меня на техподдержке, так что спешу воспользоваться вашими советами. Ещё тогда остановился на связке nginx + php-fpm, nginx + hhvm попробую как будет время у себя в песочнице. К проиводительности сайта сейчас вопросов нет, посещаемость небольшая. Сделал реврайт с помощью хуков, всё работает: https://gist.github.com/andrey-hohlov/fac7c418f099...

[Андрей Хохлов]

По поводу авторизации через апи. Расскажу как оно работает, без ссылок.

На сайте 1 по нажатию кнопки "Войти" пользователь переходит на сайт 2, где авторизуется. После авторизации происходит редирект на 1/auth/ с параметром ?token=%token%. Токен временный, действует полчаса, уникален для пользователя.

Далее идет обращение к api (file_get_contents) с передачей этого токена. Если токен действующий, то возвращается json, содержащий данные о пользователе.

Этот json я разбираю, в нем есть id (32-значный хэш от id пользователя на сайте 2), который я использую в качестве id пользователя у себя.

Если пользователя с таким id нет - создаю и авторизую, если есть - обновляю данные и авторизую.

Если api вернет данные с id = %id_админитсратора%, вместо хэша, то пользователь авторизуется как администратор. Но насколько реально подменить ответ апи?..
Понимаю что наверное лучше бы хранить этот хэш не в качестве id пользователя, а в другом поле.

[Андрей Хохлов]

Наврал, hash не в качестве id пользователя, а в качестве имени пользователя.

На работу api авторизации на том сайте повлиять я никак не могу, т.е. работать нужно с теми методами которые оно предоставляет.

[Игорь Воротнёв]

Андрей Хохлов: ну, в вашем случае реализация вполне рабочая, изначально я подозревал более упрощенную процедуру. Так что можно не заморачиваться - работает, и хорошо.

По коду в гисте - да, все именно так. Удобнее ведь, правда?

[Андрей Хохлов]

Удобнее не то слово. Спасибо большое за науку)

[Игорь Воротнёв]

Андрей Хохлов: На здоровье)

Answer 2

[Максим Гречушников]

а зачем апач?

Comments

[Андрей Хохлов]

Если вы про nginx+phpfm vs nginx+apache, то это тема для отдельной дискуссии, выходящей за рамки вопроса.
В рамках вопроса мы имеем указанную выше конфигурацию сервера (вполне конкурентоспособную), с ней и работаем.

[yarofon]

andrhohlov: а заведите, мне тоже интересно - в чем плюсы, кроме "так уже работает"

[Эргил Осин]

yarofon: а плюсов не будет у варианта с апачом. Одни только минусы. Так что заводить тему смысла нет.

[Максим Гречушников]

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

[Андрей Хохлов]

Заоффтопили вопрос) благо решение нашел (как обычно и бывает) сразу после того как его запостил.

maxyc_webber, надеюсь мой ответ не показался слишком грубым

Так получилось, что пришлось столкнуться с настройкой VPS под wordpress. Перелопатил кучу гайдов и статей (например habrahabr.ru/company/selectel/blog/230333 ) и как-то так получилось что сделал apache+nginx.
В целом кто-то советует так, кто-то nginx + php-fpm (на очереди кстати попробовать её). Часто в комментариях холивары чуть не с переходом на личности...
Во всём этом великолепии конкретных цифр не увидел, да и как понимаю от проектов зависит.

[Максим Гречушников]

andrhohlov: если решитесь попробовать изучите (хотя чего там изучать) nginx-boilerplate
там даже визуальный редактор настроек есть

[Игорь Воротнёв]

Андрей Хохлов: nginx + php-fpm это уже прошлый век, попробуйте nginx (с SPDY, скоро HTTP/2) + hhvm (c php-fpm в качестве fallback). Разница с апачем не то что большая, она космическая. Особенно при нагрузках. Да и сам php-fpm + nginx в разы шустрее и стабильнее апача. Единственная прелесть Apache, секрет из-за которого его юзнают на shared-хостингах и тд - потому что .htaccess. Потому что можно включать-выключать и менять настройки для каждого юзера/сайта или даже папки на лету. В ущерб производительности, но удобно.