Ответ

AK666 20.11.2013 13:46

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

ну это понятно

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

а если пользователей сотни тыс - то сдохнет любой СКЛ читать и писать в одну таблицу плюс пойдут всякие блокировки. и тогда тут уже начинаются шарды :) с их головняком
либо можно хранить в пуле мемкешед серверов, но у парсера (надеюсь пока) есть проблемы с подключением к пулу, в котором хоть один из серверов не отвечает.

Еще более строгой защитой может так же являться привязка не просто куки к идентификатору пользователя, а ip-адрес клиента + кука для получения идентификатора клиента.

о! вот тут я готов убивать кто такое делает :) когда у меня несколько исходящих каналов - пользоваться такими сервисами - не реально, особенно доставляет когда каналы стоят в режиме балансировки: на каждый чих надо вводить имя и пароль и не факт что после отправки их на сервер я опять не попаду на страницу логовки ибо "у вас сменился ИП адрес". .

parser+fastcgi+nginx и auth_request_set, AK666 19.11.2013 04:51 / 19.11.2013 04:55
- Вы неправильно отдаете заголовки, dmx102 19.11.2013 12:11 / 19.11.2013 12:20
  - Ответ, AK666 19.11.2013 13:40
    - В Nginx заголовки транслируются в отличии от парсера с нижним подчеркиванием, dmx102 19.11.2013 16:10
      - "отправлять заголовки на авторизацию прямо из парсера? Это ведь очень просто", AK666 19.11.2013 18:33
        Все же давайте теперь разберемся, интересно стало..., dmx102 19.11.2013 19:13
        Ответ, AK666 19.11.2013 19:28
        Потому что ваш скрипт авторизации используется только для получения статуса 200,401,403 все остальное игнорируется (-), dmx102 19.11.2013 19:42
        неа: http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html#auth_request_set (-), AK666 19.11.2013 19:45
        Ответ, dmx102 19.11.2013 21:25
        Ответ, dmx102 19.11.2013 21:37 / 19.11.2013 21:38
        РЕШЕНИЕ ПРОБЛЕМЫ . Спасибо dmx102 за наводку, AK666 19.11.2013 22:30 / 19.11.2013 22:31
        На самом деле лучше всего авторизацию делать через html-форму! (-), dmx102 20.11.2013 00:50
        почему?, AK666 20.11.2013 11:10
        Потому :), dmx102 20.11.2013 12:22 / 20.11.2013 12:41
        Ответ, AK666 20.11.2013 12:53
        Ответ, dmx102 20.11.2013 13:16 / 20.11.2013 13:17
        Ответ, AK666 20.11.2013 13:46
        Ответ, dmx102 20.11.2013 14:07 / 20.11.2013 14:09
        Ответ, AK666 20.11.2013 14:27 / 20.11.2013 14:31
        По поводу авторизации, max_rip 20.11.2013 22:10
        Это проблема вашего маршрутизатора, max_rip 20.11.2013 21:59
        Ага, каждой конторе выдать AS и будет всем счастье. , Sumo [M] 20.11.2013 22:07
        На счет stateless полностью согласен.., но, 21.11.2013 00:32
        Re: Поэтому привязка куки к IP — это натуральный идиотизм, max_rip 20.11.2013 22:16
        В IPB этот ужас достал сильно, благо он отключается в настройках..., Sumo [M] 20.11.2013 22:28
        Ответ, dmx102 20.11.2013 14:54 / 20.11.2013 16:11
        Господа, а вы не хотите это обсуждение вынести в отдельный тред? :) (-), Sumo [M] 20.11.2013 14:24 / 20.11.2013 14:25
        следующий вопрос, AK666 19.11.2013 22:33
        $http_auth[^taint[as-is][$env:HTTP_AUTHORIZATION]] (-), dmx102 20.11.2013 00:51
        не в ту сторону, AK666 20.11.2013 11:05
        Что мешает сделать $response:x-auth-name[^taint[as-is][$userData.$UIN.Name]] ?, dmx102 20.11.2013 12:26 / 20.11.2013 12:29
      - Ответ, AK666 19.11.2013 17:55 / 19.11.2013 18:07

Новости	FAQ	Авторы	Документация	В действии	Библиотека
Инструменты	Полезные ссылки	Хостинги	Скачать	Примеры	Форум