Сообщения

1

PHP / Авторизация на сайте

« : 25 Мая 2005, 15:58:31 »

Дык проще конечно, но еще один смысл такого безобразия в том, что получается прозрачная для пользователя авторизация - логин и пароль ему придется вводить только один раз в html форму, а по сети в заголовках каждого реквеста не будут передаваться настоящие логин и пароль ( это принимая во внимание что mod_auth_digest все-таки экзотическая вещь и все в основном юзают обычный mod_auth :)

2

PHP / Авторизация на сайте

« : 25 Мая 2005, 15:16:39 »

Хотя на самом деле это предубеждение что ограничить доступ можно только через mod_auth, а куки нужно проверять только из php. Никто не мешает по каждому событию удачного входа переписывать .htaccess - обновлять в нем список сессионных кук залогиненных пользователей и разграничивать доступ только на уровне апча :)  Например если есть mod_setenvif и ведется список идентификаторов активных сессий, можно сказать что-то вроде

Код: [Выделить]

ErrorDocument 403 "http://site.com/login_page.php"
SetEnvIf Cookie "061412e4a03c02f9902576ec55ebbe77" user_allowed
SetEnvIf Cookie "5705e1164a8394aace6018e27d20d237" user_allowed
Order Deny,Allow
Deny from all
Allow from env=user_allowed
тогда пользователей с этими двумя сессионными куками пустят в папку с таким .htaccess, а остальных перебросят на страничку для ввода пароля. То же самое можно организовать и через mod_rewrite, но нагрузка на сервер будет выше.
Смысл всего этого безобразия в том, что при большом числе пользователей и большом числе файлов в закрытой папке, событие добавления нового пользователя (удачного логина и обновления .htaccess) происходит в среднем в 80-150 раз реже, чем событие запроса чего-либо из защищенной папки. И php скрипт запускается во столько же раз реже. А вероятность 500-й ошибки от поступления запроса в момент когда .htaccess еще не закончил перезаписываться очень маленькая - у меня на одном сервере с постоянно висящими 80-100 онлайновыми пользователями это случается в среднем раза 3 в месяц.

3

PHP / Сессии, куки и авторизация

« : 08 Февраля 2004, 14:02:50 »

Вот :-) Теперь совершенно другое дело и совершенно согласен :-)
И не буду записывать :-)
PS Хотя это скорее всего пройдет со временем :-) Я тоже лет 5-6 назад считал что "достаточно разбираюсь" во многих вещах, но надеюсь уже переболел :-)
И все :-) Не бейте сильно - флудить завязал :-)

4

PHP / Сессии, куки и авторизация

« : 08 Февраля 2004, 13:35:42 »

да точно - насчет гета это и я ступил :-)
но все равно большинство вещей пишутся под включенные куки :-)
Насчет лепета, явасрипта и неправильных часов на клиенте есть древний способ - в заголовке html кода прямо на первой странице пишем например



в clienttime.php убираем три последних цифры у $_GET["t"], сравниваем полученную цифру с time() на сервере и записываем разницу в сессии. Ну а потом зная эту разницу легко поставить куку на точно заданное время именно по часам на клиентской машине.

Кроме того :-) не нам судить о целях и "правильности" Вариантов в жизни бывает очень много и "правил" на все варианты не напасешся, а ответ "нельзя" это совсем не то, что "можно, но не стоит"

5

PHP / Сессии, куки и авторизация

« : 08 Февраля 2004, 11:23:30 »

RomikChef
Вообще конечно все это звучит по меньшей мере смешно и крайне неубедительно, но спорить не буду :-)
Просто советую почитать спецификацию на заголовок Set-Cookie, обратить внимание на "GMT" в той строчке кода и проверить как это работает в реальной жизни :-) А если куки отключены никто не мешает это проверять и передавать идентификатор сессии гетом :-)  
И хотя я тоже не вижу зачем это может пригодиться, но человек спросил, а отвечать однозначно и неверно-то зачем?
PS Если на клиенте часы стоят неправильно, то конечно может не сработать, но и с неправильно установленными часами можно бороться используюя комбинацию яваскрипта и пхп :-)
PPS Иногда заказчики "реальных программ" хотят очень странных вещей, а наше дело не рассуждать о невозможности, а искать пути разрешения :-)

6

PHP / Сессии, куки и авторизация

« : 08 Февраля 2004, 03:02:53 »

RomikChef:
Сессия храниться до тех пор пока открыто окно браузера???
совершенно верно

Кстати по-моему совершенно необязательно :) Сессионные данные на сервере могут и дольше храниться :) и все зависит от значения session.gc_maxlifetime в php.ini. Просто обычно там же пишут session.cookie_lifetime = 0 и кука сессионная ставится без указания времени жизни и живет только до тех пор пока открыто текущее окно браузера. Т.е. первый вызов session_start(); или попытка что-нибудь записать в сессию инициирует выдачу заголовка типа

Set-Cookie: PHPSESSID=b9118d27f8abb0337a87b447daa2cc12; path=/

(где PHPSESSID это значение по умолчанию session.name в php.ini)
и первую и вторую чать этого выражения легко определить в скрипте. Например session_name(); вернет строку "PHPSESSID", а session_id(); вернет строку "b9118d27f8abb0337a87b447daa2cc12".
Ну и поскольку при выдаче подряд двух заголовков Set-Cookie более высокий приоритет имеет переданный последним, никто не мешает нам продлить время жизни куки даже не трогая ini_set :)
Например на 10 минут:

session_start();
header("Set-Cookie: ".session_name()."=".session_id()."; expires=".gmdate ("l, d-M-y H:i:s", (600+time()))." GMT; path=/;");

При таком раскладе сессионная кука будет передаваться на сервер после закрытия и открытия заново браузера и если сессионные данные на сервере живы (а живут они обычно вроде бы 24 минуты по умолчанию ?), то все получится :)