Ответ

dmx102 20.11.2013 14:54 / 20.11.2013 16:11

ну вот пока (Украина) ни один банк с которым я работаю в куки ИП не пишут

Конечно ip в куки никто не пишет, ip надо писать в таблицу сессий в виде отдельной графы или хеш от ip + session_cookie

О! а вот чем тогда кука лучше HTPP_AUTH ? перехватить-то можно и то и то :)

Тем, что перехватив сессию, злоумышленник не будет знать ваш пароль. Именно по этому и сделано на большинстве сервисов смена пароля после ввода старого. Чтобы не было достаточным перехватить сессию и сменить пароль.

а в случае с https + HTTP_AUTH - то, как по мне, гемморроя с хранением кук на стороне сервера сильно меньше (ибо НЕТУ этого хранения, которое ещё и распределенным должно быть)

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

а если бэкендов несколько? на САН надо таблицы писать? а если дописывать ещё и с разных parser-сессий - то блокировки опять возникнуть же могут.

МОЕ ЛИЧНОЕ МНЕНИЕ: зачем держать несколько бекэндов с одинаковым функционалом? Я имею введу почему не разнести по бекэндам разные сервисы, как то сделано у ВКонтакта? Дублирование бекэндов можно делать с копией на случай непредвиденного падения первого.
А в рамках одного сервиса делать микрокеширование для снятия нагрузки.

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

$salt[internal_strong_password]
$cookie:session[lkjvpiubwepijqbsdkjfbsdapkjbf]
$cookie:userid[123]
$cookie:valid[^math:md5[$cookie:session$cookie:userid$salt]]

Но это лишь как идея куда двигаться

---