forum.lissyara.su

Добавлено: **2008-12-18 1:14:27**

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

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

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

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

Добавлено: **2008-12-18 6:30:38**

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

Добавлено: **2008-12-18 6:35:39**

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

Добавлено: **2008-12-18 12:04:48**

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

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

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

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

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

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

Добавлено: **2008-12-18 12:11:21**

zg писал(а):
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.

Добавлено: **2008-12-18 12:16:25**

jeehadina писал(а):документацию читать не вредно

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

jeehadina писал(а):it compatible with more browsers

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

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

Добавлено: **2008-12-18 15:21:48**

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

Добавлено: **2008-12-18 17:32:05**

MAK писал(а):все-же это лучше, чем сессия в урле.

почему?

MAK писал(а):вроде как "сам драк, раз куки отключил"

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

Добавлено: **2008-12-18 19:40:50**

zg писал(а):почему?

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

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

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

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

Добавлено: **2008-12-18 20:18:23**

MAK писал(а):в чем их ненадежность?

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

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

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

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

Добавлено: **2008-12-18 20:41:14**

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

Добавлено: **2008-12-18 20:51:29**

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

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

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

Добавлено: **2008-12-18 21:17:54**

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

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

Добавлено: **2008-12-18 21:27:36**

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

Добавлено: **2008-12-18 21:34:03**

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

Добавлено: **2008-12-19 6:37:10**

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

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

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

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

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

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

ProFTP писал(а):обязательно разве ставить домен в куки?

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

Добавлено: **2008-12-19 10:21:58**

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

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

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

Добавлено: **2008-12-19 12:47:02**

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

.htaccess

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

php_value session.cookie_domain .domain.name

или

php.ini

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

session.cookie_domain = '.domain.name';

Добавлено: **2008-12-19 14:53:03**

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

(зевая) ага

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

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

forum.lissyara.su

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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