[PHP] Задачка про авторизацию.

[Alex Keda]

есть домен.
скажем - domain.su
есть пачка субдоменов
vasya.domain.su
petya.domain.su

эти субдомены - своего рода проекция виртуальной директории на основном - domain.su/users/vasya, domain.su/users/petya
и сайт в реальности везде один.

======
надо как-то замутить авторизацию.
чтобы вне зависмости от точки авторизации оно работало везде в пределах этой конструкции - на субдомене, или на основном домене.

идей чё-то нет вообще... куку на другой домен не поставшь, иначе я не умею =(((

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[jeehadina]

авторизационную сессию можно передавать либо куком либо по id (sid=(и тут 32 символа). в урле.
треьего нет.
а почему куку нельзя поставить?
если всетаки можно поставить куку то '.example.com' вместо '/' и будет гуд.

[paradox]

думаю должен быть какойто модуль для пхп под апач
а иначе это для всех сайтов будут include модуль с сессией

[zg]

а почему куку нельзя поставить?

она на домен даётся, браузер не должен давать чужие куки другим доменам.

чтобы вне зависмости от точки авторизации оно работало везде в пределах этой конструкции - на субдомене, или на основном домене.

обычно ставят редирект

Можно и через переменные номер сессии передавать http://ru2.php.net/manual/ru/function.o ... te-var.php

Можешь использовать именные сессии http://ru2.php.net/manual/ru/function.session-name.php вариантов в принципе много.

[jeehadina]

а почему куку нельзя поставить?

она на домен даётся, браузер не должен давать чужие куки другим доменам.

документацию читать не вредно

The domain that the cookie is available. To make the cookie available on all subdomains of example.com then you'd set it to '.example.com'. The . is not required but makes it compatible with more browsers. Setting it to http://www.example.com will make the cookie only available in the www subdomain. Refer to tail matching in the » spec for details.

[zg]

документацию читать не вредно

-))) тебя строчка эта не смущает?

it compatible with more browsers

с куками есть много траблов, я бы на них особо не рассчитывал

UPD вся поднаготная сессий http://ru2.php.net/manual/ru/session.configuration.php

[MAK]

кука, поставленная на домен .domain.su будет видна на всех его поддоменах.
все-же это лучше, чем сессия в урле.
обычно сначала пытаются воткнуть куку, а если не получилось, передают сессию в урле(вроде как "сам драк, раз куки отключил").

[zg]

все-же это лучше, чем сессия в урле.

почему?

вроде как "сам драк, раз куки отключил"

кука - самый ненадёжный источник пользовательских данных, да ещё и нарушает кое-какие права человека.

[MAK]

почему?

потому что а) урл короче и б) можно избежать проблем с HTTP_REFERER

кука - самый ненадёжный источник пользовательских данных, да ещё и нарушает кое-какие права человека.

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

в чем их ненадежность?

[zg]

в чем их ненадежность?

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

Для клиента весьма вероятно цепануть вирус, для сервера весьма вероятна подмена данных.

однако это не мешает гигантам веб-индустрии использовать их.

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

[jeehadina]

не использовать куки из-за какой-то боязни - маразм.

[zg]

не использовать куки из-за какой-то боязни - маразм.

это не маразм, а параноя -))) если быть точным.

Но я не выступал против использования кук вообще, просто не стоит возлагать на них больше чем нужно.

[ProFTP]

в куках еще можно хранить дамп объектов для высоко нагруженных систем, но говорят что с включенным кэширвоанием не сильно быстро, так как храниться на сервере в share memory

JSON::XS - JSON serialising/deserialising, done correctly and fast
http://search.cpan.org/~mlehmann/JSON-XS-2.231/XS.pm

[Alex Keda]

кстати - никто не помнит - размер всех заголовков килобайтом ограничен, или тока куков?
=======
вспомнил что на одном проекте при первом заходе юзера с поисковика рефер покодированный base64 в куку кладётся, а если юзер регается - в базу перкладывается....
статистика такая... запросы большие бывают

[ProFTP]

обязательно разве ставить домен в куки?
я домен в куки не ставлю - все равбответ...
(только что посмотрел домен стоит domain.ltd, без домена по-моиму работает)

[zg]

кстати - никто не помнит - размер всех заголовков килобайтом ограничен, или тока куков?

в стандарте http1.1 ничего про общий размер заголовоков не нашёл. Если и есть ограничения, то они накладываются браузером.

кстати про длину строки запроса

Код: Выделить всё

   Протокол HTTP не накладывает a priori никаких ограничений на длины
   URI. Серверы ДОЛЖНЫ быть способны обработать URI любого ресурса,
   который они обслуживают, и им СЛЕДУЕТ быть в состоянии обрабатывать
   URI неограниченной длины, если они обслуживают формы, основанные
   на методе GET, которые могут генерировать такой URI. Серверу
   СЛЕДУЕТ возвращать код состояния 414 (URI запроса слишком длинный,
   Request-URI Too Long), если URI больше, чем сервер может обработать
   (смотрите раздел 10.4.15).

      Обратите внимание: Серверы должны быть осторожны с URI, которые
      имеют длину более 255 байтов, потому что некоторые старые
      клиенты или прокси-сервера не могут правильно поддерживать
      эти длины.

обязательно разве ставить домен в куки?

нет, куки принадлежат тому домену, на который пришёл запрос. Указывать домен нужно для большей секурности.

[MAK]

zg, прости, но это что-то больше, чем паранойя. )
У нас есть всего 2 способа идентифицировать уникальную сессию(точнее 2 разновидности единственного решения). Каким-то образом передавать уникальный идентификатор сессии. 1) передавать его в гет/пост параметре, 2) передавать его в куке. В обоих случаях это будет одна строка в заголовке запроса клиента. Их одинаково легко подделать.
Все остальные проверки(ip, юзер_агент...все что угодно, что передает серверу браузер) лишь дополняют эти способы. Тем самым усложняя жизнь кул-хуцкерам, которые нашли id сессии.

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

ProFTP, не стоит в куках хранить много данных. Ведь раз полученная кука клиентом, в дальнейшем будет постоянно передаваться на сервер, неоправдано увеличивая тем самым исходящий трафик. Есть некий предел(у каждого проекта свой) за который нельзя выходить. Для меня, в общем случае, примерно, не более 10 кук, каждая длинной не более 255 символов.

[Volodymyr]

По умолчанию идентификатор пишется все-равно в куку. Так что действительно самый простой способ через разрешение имени домена через точку.

.htaccess

Код: Выделить всё

php_value session.cookie_domain .domain.name

или

php.ini

Код: Выделить всё

session.cookie_domain = '.domain.name';

[zg]

zg, прости, но это что-то больше, чем паранойя. )

(зевая) ага

По умолчанию идентификатор пишется все-равно в куку

по умолчанию пхп передаёт и куку и переменную. Если кука вернулась, то использует её, если нет, продолжает оверврайтить переменную во всех ссылках и формах.