Заобикаляме лимита за търсене в LinkedIn, играейки с API

Лимит

Има такова ограничение в LinkedIn — Лимит за търсене в бизнеса. Вероятно, както и аз до неотдавна, никога не сте се сблъсквали с него и не сте чували за него.

Същността на лимита е, че ако извършвате търсене на хора извън вашите контакти твърде често (няма точни метрики, алгоритъмът решава на база вашите действия — колко често и много търсите, добавяте хора), то резултатът от търсенето ще бъде ограничен до три профила, вместо 1000 (по подразбиране 100 страници по 10 профила на страница). Лимитът се нулира в началото на всеки месец. Естествено, премиум акаунтите нямат такова ограничение.

Но неотдавна, за един малък проект, започнах да експериментирам много с търсене в LinkedIn и внезапно получих това ограничение. Естествено, не ми хареса, тъй като не го използвах за търговски цели, затова първата ми мисъл беше да проуча правилото и да се опитам да го заобиколя.

[Важно уточнение — материалите в статията са представени единствено за информационни и учебни цели. Авторът не насърчава тяхното използване за търговски цели.]

Проучване на проблема

Имаме: вместо десет профила с пагинация, търсенето връща само три, след които следва блок с “препоръка” за премиум акаунт и под него вървят размити и непровеждащи профили.

Веднага ръката се протяга към конзолата за разработчици, за да видим тези скрити профили — възможно е да можем да свалим някои стилове, които налагат размазване, или да извлечем информация от блока в разметката. Но, както се очакваше, тези профили са просто картинки-заглушки и не съхраняват никаква информация.

Добре, сега да погледнем в раздела Network и да проверим дали действително се задейства алтернативният резултат от търсенето, който връща само три профила. Намираме интересуващия ни заявка към “/api/search/blended” и разглеждаме отговора.

Профилите идват в масив `included`, но в него има общо 15 елемента. В този случай, първите три от тях са обекти с допълнителна информация, всеки обект съдържа информация за конкретен профил (например, дали профилът е премиум).

Следващите 12 са реални профили — резултати от търсене, от които ще ни покажат само три. Както вече може да се предположи, показва само тези, за които идва допълнителна информация (първите три обекта). Например, ако вземем отговора с профила без лимит, ще получим 28 същности — 10 обекта с допълнителна информация и 18 профила.

Отговор за профил без лимит

Защо профилите идват повече от 10, докато се запитва точно 10, и те не участват никак в показването, дори на следващата страница няма да ги има — все още не знам. Ако анализираме URL на запитването, можем да видим, че count=10 (колко профила да върне в отговора, максимум 49).

Ще се радвам на всякакви коментари по този въпрос.

Експериментираме

Добре, най-важното сега е, че вече знаем със сигурност — профилите в отговора са повече, отколкото ни показват. Значи можем да извлечем повече данни, независимо от лимита. Нека опитаме да извлечем API сами, направо от конзолата, с помощта на fetch.

Очаквано, получаваме грешка, 403. Това е свързано с безопасността, тук не изпращаме CSRF токен (CSRF в Уикипедия. В две думи — към всяко запитване се добавя уникален токен, който се проверява на сървъра за автентичност).

Може да се копира от всяко друго успешно запитване или от бисквитките, където се съхранява в полето ‘JSESSIONID’.

Къде да намерим токенаЗаглавие на друго запитване:

Или от бисквитките, направо през конзолата:

Опитваме отново, този път предаваме в fetch настройки, в които указваме параметър в заглавката нашия csrf-токен.

Успех, получаваме всичките 10 профила. :tada:

Поради разликата в заглавките структурата на отговора е малко по-различна от това, което получаваме в оригиналното запитване. Може да получим същата структура, ако добавим ‘Accept: ‘application/vnd.linkedin.normalized+json+2.1’, към нашия обект, до csrf токена.
Пример на отговор с добавеното заглавие

Повече за заглавието Accept

Какво следва?

След това можем да редактираме (на ръка или автоматизирано) параметъра `start`, който указва индекса, от който ще ни върнат 10 профила (по подразбиране = 0) от целия резултат от търсенето. Иначе казано, увеличавайки го с 10 след всяко запитване, получаваме обична постранична обработка, по 10 профила на всяко заявка.

На този етап имах достатъчно данни и свобода, за да продължа работата си по личния проект. Но беше грях да не опитам тези данни да бъдат визуализирани на място, след като вече ги имам. Няма да се спрягаме на Ember, който се използва на фронта. На сайта беше интегриран jQuery и припомняйки си основния синтаксис, може да се създаде следното за секунди.

Код на jQuery

/* рендер блока, принимаем данные профиля и вставляем блок в список профилей используя эти данные */
const  createProfileBlock = ({ headline, publicIdentifier, subline, title }) => {
    $('.search-results__list').append(
        `<li class="search-result search-result__occluded-item ember-view">
            <div class="search-entity search-result search-result--person search-result--occlusion-enabled ember-view">
                <div class="search-result__wrapper">
                    <div class="search-result__image-wrapper">
                        <a class="search-result__result-link ember-view" href="/bg/in/${publicIdentifier}/">
                            <figure class="search-result__image">
                                <div class="ivm-image-view-model ember-view">
                                    <img class="lazy-image ivm-view-attr__img--centered EntityPhoto-circle-4  presence-entity__image EntityPhoto-circle-4 loaded" src="http://www.userlogos.org/files/logos/give/Habrahabr3.png" />
                                </div>
                            </figure>
                        </a>
                    </div>
                    
                    <div class="search-result__info pt3 pb4 ph0">
                        <a class="search-result__result-link ember-view" href="/bg/in/${publicIdentifier}/">
                            <h3 class="actor-name-with-distance search-result__title single-line-truncate ember-view">
                                ${title.text}
                            </h3>
                        </a>

                        <p class="subline-level-1 t-14 t-black t-normal search-result__truncate">${headline.text}</p>

                        <p class="subline-level-2 t-12 t-black--light t-normal search-result__truncate">${subline.text}</p>
                    </div>
                </div>
            </div>
        <li>`
 );
};

// взимаме апи, получаваме данни и рендерираме профили
const fetchProfiles = () =&gt; {
 // токен
 const csrf = 'ajax:9082932176494192209';
 
 // обект с настройки на заявката, предаваме токена
 const settings = { headers: { 'csrf-token': csrf } }

 // урл на заявката, с динамичен индекс на старт в края
 const url = `https://www.linkedin.com/voyager/api/search/blended?count=10&amp;filters=List(geoRegion-jp0,network-S,resultType-PEOPLE)&amp;origin=FACETED_SEARCH&amp;q=all&amp;queryContext=List(spellCorrectionEnabled-true,relatedSearchesEnabled-true)&amp;start=${nextItemIndex}`; 
 /* правим заявка, за всеки профил в отговора извикваме рендер блока, и след това инкрементираме стартовия индекс с 10 */
 fetch(url, settings).then(response =&gt; response.json()).then(data =&gt; {
 data.elements[0].elements.forEach(createProfileBlock);
 nextItemIndex += 10;
});
};


// изтриваме всички профили от списъка
$('.search-results__list').find('li').remove();
// вмъкваме бутон за зареждане на профили
$('.search-results__list').after('<button id="load-more">Зареждане на още</button>');
// добавяме функционалност на бутона
$('#load-more').addClass('artdeco-button').on('click', fetchProfiles);

// задаваме по подразбиране индекса на профила за заявката
window.nextItemIndex = 0;

Ако изпълните това директно в конзолата на страницата за търсене, ще добави бутон, който зарежда 10 нови профила при всяко натискане и ги визуализира в списък. Разбира се, токена и URL-то трябва да се сменят с необходимите. Профилният блок ще съдържа име, длъжност, местоположение, линк към профила и картинка-заглушка.

Заключение

Така, с минимални усилия, успяхме да намерим уязвимо място и да възвърнем търсенето без ограничения. Достатъчно беше да анализираме данните и техния маршрут, да надникнем в самия заявка.

Не мога да кажа, че това представлява сериозен проблем за LinkedIn, тъй като не нанася никаква заплаха. Максимумът е загубена печалба заради подобни 'заобиколни' стратегии, които позволяват да не се плаща за премиум. Може би такъв отговор от сървъра е необходим за коректната работа на другите части на сайта, или просто е мързел на разработчиците и недостиг на ресурси, които не позволяват да се направи както трябва. (Ограничението е въведено през януари 2015 г., преди това не е имало лимит).

P.S.

Естествено, кодът на jQuery е доста примитивен пример за възможностите. В момента съм създал разширение за браузър за личните си нужди. То добавя контролните бутони и визуализира пълни профили с картинки, бутон за покана и общи връзки. Плюс динамично събира филтри за локации, компании и други, изтегля токена от бисквитките. Така че няма нужда да хардкодим вече. Освен това добавя допълнителни настройки, а-ла 'колко профила да се запитват наведнъж, до 49'.

Все още работя по това допълнение и планирам да го пусна с отворен достъп. Пишете, ако ви е интересно.

Източник: habr.com