Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Кроссдоменная авторизация средставми nginx
- To: "nginx-ru@xxxxxxxxx" <nginx-ru@xxxxxxxxx>
- Subject: Re: Кроссдоменная авторизация средставми nginx
- From: Васильев "Zmey!" Олег <zmey1992@xxxxx>
- Date: Wed, 08 May 2013 14:36:48 +0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1368009408; bh=HP2ZtTVMGnVnBLDoS6fje+x4jevX3f+hVubM2qMPaOo=; h=From:To:In-Reply-To:References:Subject:Date; b=eSegey9dxqPxxZ6tmt0tfusi5HLhT6EhONvJfYCg/DLWd4i8YS2REaPzL4nOowe0G PC0jpOJEuDWNQcSW2VlEklRbnrprbEFhdvhMAQqnd7Apa0HeLwrl9CyBTJfIDX7Xxy Jyrc85n1UJYkbdBYs3CQG40CMGghLgI8LYKQtQNw=
- Envelope-from: zmey1992@xxxxxxxxx
- In-reply-to: <CALUn_U7OH=C-oewLqc3Frm0TXKsBbHZ6Fyvsyqv-zrh8w1L+DA@mail.gmail.com>
- References: <15710675846.20130505202257@gmail.com> <1370921368000486@web13h.yandex.ru> <CALUn_U7OH=C-oewLqc3Frm0TXKsBbHZ6Fyvsyqv-zrh8w1L+DA@mail.gmail.com>
Ну, если принципиально (а автор писал, что его смущает лишь кроссдоменность),
до для авторизации можно сделать отдельный server{} на IP (без домена) или даже
лучше порту. Допустим, получим следующую схему:
- Заходим на 1.2.3.4:1025/domain
- Ставим куку
- Редиректим на domain.
Один из вариантов.
08.05.2013, 13:27, "Danila Shtan" <danila@xxxxxxxx>:
> Проблема с auth_basic не в том, как её наследовать, а в том, что на
> domain.com, site.domain.com, trash.domain.com пользователю придется вводить
> пароли отдельно.
>
> Д.
>
> 2013/5/8 Васильев "Zmey!" Олег <zmey1992@xxxxx>
>> Занесите auth_basic в контекст http {}, все server{} внутри унаследуют его
>> (только что проверил).
>>
>> 05.05.2013, 18:23, "psixozzz@xxxxxxxxx" <psixozzz@xxxxxxxxx>:
>>> Здравствуйте, Nginx-ru.
>>>
>>> Дано: домен с большим количеством поддоменов. Задача:
>>> открыть доступ только для ограниченного круга лиц, включая мобильные
>>> клиенты. Крайне желательно ограничиться средствами nginx, не
>>> вмешиваясь в скрипты сайта. Авторизация нужна только для того, чтобы
>>> не могли зайти люди "с улицы". Т.е. вполне подойдет что-то слабенькое,
>>> как, например, факт наличия куки у клиента и т.п. Никак не могу
>>> придумать, как это реализовать.
>>> Basic-авторизация не подходит, т.к. она не кроссдоменная.
>>> Рассматривал вариант когда сайт не пускает никого, у кого
>>> нет определенной куки, а получить ее можно, зайдя на определенный урл
>>> внутри сайта. Возникли проблемы с внесением изменений в текущую
>>> конфигурацию nginx:
>>>
>>> if ($cookie_edws != '1033'){
>>> return 444;
>>> }
>>>
>>> location = /auth_url {
>>> add_header Set-Cookie
>>> "lcid=1033;Domain=.domain.com;Path=/;Max-Age=31536000";
>>> rewrite ^(.*)$ domain.com persistent;
>>> }
>>>
>>> if (!-e $request_filename) {
>>> rewrite ^(.*)$ /index.php break;
>>> }
>>>
>>> Таким образом, если физически auth_url не существует, то управление в
>>> location = /auth_url не попадет никогда, а всегда будет передано в if
>>> (-e $request_filename). Даже если вмешаться в структуру сайта (что
>>> неприемлимо) и создать файл auth_url, то в location управление не
>>> попадет из-за существования if ($cookie_edws != '1033'). Замкнутый
>>> круг какой-то.
>>>
>>> Может многоуважаемый All подскажет как быть?
>>>
>>> --
>>> С уважением,
>>> Psixozzz mailto:psixozzz@xxxxxxxxx
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru@xxxxxxxxx
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@xxxxxxxxx
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> ,
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|
