Є html-сторінка статті, доступна всім. Треба на ній показати посилання
"Редагувати", доступну тільки деяким користувачам.
Зі статті (test1.html) підключаю по SSI посилання (test2.html), але чомусь
права на неї не перевіряються. При прямому зверненні з браузера - перевіряються.
Як змусити перевіряти при SSI?
(Include virtual теж пробував)
location = /test2.html auth_request / test_auth;
>
location = / test_auth return 403;
>
Виводиться при зверненні до test1.html:
test1
test2
Виводиться при зверненні до test2.html (так і повинно):
<403>
Модулі контролю доступу (як то auth_basic, access і auth_request)
не перевіряють підзапити. Передбачається, що всі необхідні
права були перевірені на етапі обробки основного запиту.
Якщо хочеться якісь ssi-фрагменти показувати в залежності від
результату auth_request, то слід використовувати auth_request для
основного запиту, і повернути позитивний результат, паралельно
встановивши додаткову змінну через auth_request_set. після
чого перевіряти змінну за допомогою, наприклад, SSI-команди "if".
Детальніше про auth_request_set в документації тут:
Post by Maxim Dounin
Hello!
Ну і так, зазначу в дужках, що можливо вам auth_request тут
взагалі не треба, а цілком вистачить звичайного <--#include. set="variable" -->,
докладніше тут:
Post by Maxim Dounin
Ну і так, зазначу в дужках, що можливо вам auth_request тут
взагалі не треба, а цілком вистачить звичайного <--#include.
set = "variable" ->,
1. За документації незрозуміло, що за "результат виконання запиту" буде в
змінної? body в змінної замість виведення на екран? $ Upstream_http_ *?
2. Це де саме використовувати? У test1.html, де include
file = "test2.html"?
3. Напевно, замість auth_request можна з test1 завжди підключати test2. А
вже при обробці test перевіряти права і повертати або порожній рядок, або
вміст файлу test2
Post by Maxim Dounin
Ну і так, зазначу в дужках, що можливо вам auth_request тут
взагалі не треба, а цілком вистачить звичайного <--#include.
set = "variable" ->,
1. За документації незрозуміло, що за "результат виконання запиту" буде в
змінної? body в змінної замість виведення на екран? $ Upstream_http_ *?
Мова про тіло відповіді.
Post by BorisK2
2. Це де саме використовувати? У test1.html, де include
file = "test2.html"?
Записати в змінну результат виконання підзапиту, далі
if'ом перевірити потрібне. Де це робити - не принципово,
варіантів маса.
Post by BorisK2
3. Напевно, замість auth_request можна з test1 завжди підключати test2. А
вже при обробці test перевіряти права і повертати або порожній рядок, або
вміст файлу test2
Мова в першу чергу про те, що SSI сам вміє підзапити, і
прикручувати до нього додатково auth_request - особливого сенсу
немає, все можна зробити засобами SSI.
Post by Maxim Dounin
Якщо хочеться якісь ssi-фрагменти показувати в залежності від
результату auth_request, то слід використовувати auth_request для
основного запиту, і повернути позитивний результат, паралельно
встановивши додаткову змінну через auth_request_set. після
чого перевіряти змінну за допомогою, наприклад, SSI-команди "if".
Спасибі за пораду!
Не виходить встановити змінну: auth_request_set $ x_allow_test2
$ Upstream_http_x_allow_test2;
Вона завжди порожня. auth_request_set $ server $ upstream_http_server; теж
порожня.
location = /test1.html auth_request / test_auth;
auth_request_set $ x_allow_test2 $ upstream_http_x_allow_test2;
>
location = / test_auth add_header X-Allow-Test2 1;
return 200;
>
test1.html:
test1
Post by Maxim Dounin
Якщо хочеться якісь ssi-фрагменти показувати в залежності від
результату auth_request, то слід використовувати auth_request для
основного запиту, і повернути позитивний результат, паралельно
встановивши додаткову змінну через auth_request_set. після
чого перевіряти змінну за допомогою, наприклад, SSI-команди "if".
Якщо мова йде про те, щоб поставити змінну в рамках
підзапиту безпосередньо з конфіга nginx'а, то замість
auth_request_set просто зробіть set, як-то так:
location = / test_auth set $ x_allow_test2 1;
return 200;
>
Простір змінних у запитів і підзапиту - загальне, так що
встановлена в підзапиті змінна буде доступна в основному
запиті. Директива auth_request_set потрібна тоді, коли мова йде
про спеціальні змінні, такі як $ upstream_http_ *, які
можуть мати різні значення в залежності від того, де саме до
них звертаються.
Тому зробив другий варіант. Логіка не html, а в конфіги, де можна
використовувати rewrite і інше, щоб безліч прав і змінних звести до
декільком.
test1.html:
test1
конфиг:
map $ cookie_user_id: $ request_uri $ allow default 0;
Тисячу двісті тридцять чотири: /path/page1.html 1;
4567: /path/page1.html 1;
>
location = /test2.html internal;
if ($ allow = 0) return 403;
>
>
>