Продолжая работать с
Livejournal используя
Indy Cookie Manager, созданный
своими руками, натолкнулся еще на одну проблему при работе с
Cookies. Проблемы с нашим
Cookie Manager уже встречались и
успешно разрешались, но жизнь не стоит на месте. Разные хитрые сайты преподносят нам все новые сюрпризы.
При работе с livejournal.com мне не удалось после успешного логина выполнить GET запрос, проблема оказалась в том, что не все Cookies передавались на livejournal в GET запросе после успешной авторизации. Первый вариант этой статьи предлагал некоторое решение, которое работало, но было неверным по своей сути. Ваш автор начал выполнять непонятные действия с очисткой параметров Cookies, не разобравшись в сути проблемы. Бывает, прошу прощения. На ошибку автору терпеливо указывал alexchet, за что ему отдельная благодарность. Но истина дороже, я в итоге понял в чем проблема и ниже приводится как я надеюсь вариант правильного решения. Первоначальный вариант этой статьи изменен, вряд ли требуется оставлять неверные решения на всеобщее обозрение.
Итак, что получалось. При последовательном выполнении GET запроса, затем POST запроса с параметрами пользователя, после которого выполнялась успешная авторизация и затем опять GET запроса оказалось, что некоторые Cookie не передавались на livejournal в последнем GET. Это происходило вследствие того, что куки, которые перед этим возвращал livejournal были с параметрами домена аж трех видов:
livejournal.com
.livejournal.com
www.livejournal.com
те куки, в параметрах домена которых был www. не передавались обратно на сервер при использовании нашего Cookie Manager вследствие некорректной работы функции GetCookieDomain. Вот скорректированный вид этой функции:
function THTTP1.GetCookieDomain(Cookie: string): string;
var i,j: integer;
begin
Result:='';
i:=Pos('domain=',Cookie);
if i=0 then Exit;
j:=PosEx(';',Cookie,i);
if j=0 then j:=Length(Cookie)+1;
Result:=Copy(Cookie,i+7,j-i-7);
// Remove www
Result:=SysUtils.StringReplace(Result,'www.','',[]);
// Remove dot
if (Result<>'') and (Result[1]='.') then
Result:=Copy(Result,2,Length(Result)-1);
end;
Смотрите также:
Оставьте свой комментарий
Вы должны быть авторизированны, чтобы оставить комментарий.
Не совсем понял, зачем такие изменения? Ведь если установить домен кука livejournal.com то условие
(Pos(GetCookieDomain(FCookieLis[i]), GetURLDomain(url))>0)
будет выполняться как для livejournal.com так и для verycoolblog.livejournal.com
Все верно, но при работе с livejournal получается такой сценарий, если смотреть сниффером:
1. GET livejournal.com. В результате возвращаются куки, в которых есть в параметрах домен livejournal.com. Эти куки запоминаются.
2. Затем делаем POST livejournal.com/login.bml с параметрами пользователя/паролем. Также возвращается много куков, в которых есть в параметрах домен livejournal.com.
3. Затем у нас два варианта – работать с доменом livejournal.com (например, изменить профиль пользователя) или же с verycoolblog.livejournal.com. Для любых следующих GET и POST браузер вырезает домен и все остальные параметры куков и любой следующий GET или POST происходит уже с такими «чиcтыми» куками. На основании какого стандарта или предписания так делает браузер, я не разбирался.
4. Если все это эмулировать в Delphi, и послылать после авторизации запросы на livejournal.com, то livejournal просит опять авторизоваться, т.е. он не принимает куки, у которых в параметрах есть домен.
5. Как все это эмулировать, рассказывает эта статья. Т.е. после авторизации POST-ом процедурой ClearCookiesOtherParams вырезаем домен и заодно все остальные параметры из куков. При этом процедура теперь WriteCookies проверяет, если домен кука пустой, то такой кук тоже записывается в запрос. В итоге этих доработок удается нормально работать с livejournal, менять профиль, например.
Все равно не понимаю.. Ведь посылаемый на сервер кук никогда не содержит информацию о домене это просто пара name=value
alexchet, все верно, здесь я неправ, признаю. Решил возникшую проблему как то неадекватно.. Благодарю, проблема оказалась просто в неправильной обработке куков с параметрами доменов в которых был ‘www.’, текст статьи исправил