[identity profile] sergeax.livejournal.com 2009-10-05 11:15 am (UTC)(link)
Потому что куки без времени жизни хранятся до закрытия всех окон этого процесса?

[identity profile] dil.livejournal.com 2009-10-05 11:16 am (UTC)(link)
а кто мешает установить им значение в виде пустой или заведомо невалидной строки?

[identity profile] pash7ka.livejournal.com 2009-10-05 11:23 am (UTC)(link)
Я предполагаю, что тут думают не о куках, а о кнопке "Назад", которая может показать предыдущую страницу не запрашивая её заново с сервера.

[identity profile] dil.livejournal.com 2009-10-05 11:29 am (UTC)(link)
предыдущая страница прекрасно показывается даже после refresh. как и все остальные.
то есть, при нажатии на Log Off никакого логаута вообще не происходит.

[identity profile] pash7ka.livejournal.com 2009-10-05 12:46 pm (UTC)(link)
А там точно по кукам авторизация? А то больше похоже на basic-авторизацию, это бы всё объяснило.

[identity profile] dil.livejournal.com 2009-10-05 01:05 pm (UTC)(link)
там не basic, а NTLM. фиг ее знает, как оно работает, но заголовки Authorisation: NTLM передаются точно не в каждом запросе

[identity profile] pash7ka.livejournal.com 2009-10-05 01:18 pm (UTC)(link)
Понятно. Тут та же фигня, толкьо с другой стороны: авторизуется HTTP-соединение целиком, вместе со всеми Keep-Alive запросами. Это, кажется, нарушение спецификации, но когда Микрософт волновали такие мелочи...

This scheme differs from most "normal" HTTP authentication mechanisms, in that subsequent requests over the authenticated connection are not themselves authenticated; NTLM is connection-oriented, rather than request-oriented. So a second request for "/index.html" would not carry any authentication information, and the server would request none. If the server detects that the connection to the client has been dropped, a request for "/index.html" would result in the server reinitiating the NTLM handshake. (link (http://curl.haxx.se/rfc/ntlm.html#ntlmHttpAuthentication))

[identity profile] dil.livejournal.com 2009-10-05 01:21 pm (UTC)(link)
по-моему, в этом случае достаточно принудительно закрыть соединение, а на следующий запрос от того же клиента, [идентифицируемого по куке], принудительно выдать 401, несмотря на правильный пароль. тогда клиент забудет, что это правильный пароль, и переспросит его у пользователя

[identity profile] pash7ka.livejournal.com 2009-10-05 01:25 pm (UTC)(link)
Ну да, в самом деле можно выдать "Connection: close", закрыть соединение и успокоится. Наверное они там не додумались до этого...

[identity profile] dil.livejournal.com 2009-10-05 01:27 pm (UTC)(link)
не, просто так недостаточно. действительно, браузер до закрытия будет помнить, что это правильный пароль от этого сайта и автоматически будет его туда отправлять при следующих соединениях.
так что один раз 401 надо будет выдать в ответ на правильный пароль

[identity profile] pash7ka.livejournal.com 2009-10-05 01:29 pm (UTC)(link)
А, точно, о памяти браузера я не подумал. :)

[identity profile] dma.livejournal.com 2009-10-05 12:57 pm (UTC)(link)
mySAP.com, circa 2001!
Только там было веселее. В рамках мести за сталинград они экспайрили сессию на сервере, и, внимание, писали "Ваша сессия истекла. Чтобы зайти на mySAP.com снова - закройте ВСЕ окна вашего браузера".

[identity profile] dil.livejournal.com 2009-10-05 03:27 pm (UTC)(link)
а просто так уже нельзя было?

[identity profile] dma.livejournal.com 2009-10-05 03:28 pm (UTC)(link)
Нет. Заходишь на сайт - а тебе вот это говорят.

Таймаут сессии причём был полчаса, что ли.

[identity profile] dil.livejournal.com 2009-10-05 03:29 pm (UTC)(link)
ненатуралы..