ProHoster > блог > Администрација > Заобиколување на ограничувањето за пребарување на LinkedIn со играње со API
Заобиколување на ограничувањето за пребарување на LinkedIn со играње со API
Граница
Постои такво ограничување на LinkedIn - Ограничување за комерцијална употреба. Исклучително е веројатно дека вие, како мене до неодамна, никогаш не сте се сретнале или слушнале за тоа.
Суштината на ограничувањето е дека ако премногу често го користите пребарувањето за луѓе надвор од вашите контакти (нема точни метрики, алгоритмот одлучува врз основа на вашите постапки - колку често и колку сте пребарувале, додавале луѓе), тогаш резултатот од пребарувањето ќе биде ограничено на три профили, наместо 1000 (стандардно 100 страници, 10 профили на страница). Границата се ресетира на почетокот на секој месец. Нормално, Премиум сметките го немаат ова ограничување.
Но, не така одамна, за проект за домашни миленици, почнав да играм многу со пребарувањето на LinkedIn и одеднаш го добив ова ограничување. Нормално, ова не ми се допадна многу, бидејќи не го користев за комерцијални цели, па мојата прва мисла беше да го проучам ограничувањето и да се обидам да го заобиколам.
[Важно појаснување: материјалите во статијата се претставени исклучиво за информативни и едукативни цели. Авторот не ја поттикнува нивната употреба за комерцијални цели.]
Го проучуваме проблемот
Имаме: наместо десет профили со страници, пребарувањето враќа само три, по што се вметнува блок со „препорака“ за премиум сметка, а подолу се заматени профили кои не можат да се кликнат.
Веднаш, раката посегнува до програмерската конзола за да ги погледне овие скриени профили - можеби можеме да отстраниме некои стилови на замаглување или да извлечеме информации од блок во ознаката. Но, сосема очекувано, овие профили се само слики од место и не се чуваат никакви информации.
Добро, сега да го погледнеме табот Мрежа и да провериме дали алтернативните резултати од пребарувањето што враќаат само три профили навистина функционираат. Го наоѓаме барањето за кое сме заинтересирани за „/api/search/blended“ и го гледаме одговорот.
Профилите доаѓаат во „вклучена“ низа, но веќе има 15 ентитети во овој случај, првите три од нив се објекти со дополнителни информации, секој објект содржи информации за одреден профил (на пример, дали профилот е премиум. ).
Следните 12 се вистински профили - резултати од пребарување, од кои само три ќе ни бидат прикажани. Како што веќе можете да погодите, ги прикажува само оние кои добиваат дополнителни информации (првите три објекти). На пример, ако го земете одговорот од профил без ограничување, ќе добиете 28 ентитети - 10 објекти со дополнителни. информации и 18 профили.
Одговор за профил без ограничување
Зошто пристигнуваат повеќе од 10 профили, иако се бараат точно 10, а тие на никаков начин не учествуваат во прикажувањето, дури ни на следната страница нема да бидат - сè уште не знам. Ако ја анализирате URL-адресата на барањето, можете да го видите тој број = 10 (колку профили да се вратат во одговорот, максимум 49).
Ќе ми биде драго да добијам какви било коментари за ова прашање.
Ајде да експериментираме
Океј, најважното нешто што сега сигурно го знаеме е дека има повеќе профили во одговорот отколку што ни покажуваат. Ова значи дека можеме да добиеме повеќе податоци, и покрај ограничувањето. Ајде да се обидеме сами да го повлечеме API-то, директно од конзолата, користејќи fetch.
Како што се очекуваше, добиваме грешка, 403. Ова се должи на безбедноста, овде не испраќаме токен CSRF (CSRF на Википедија. Накратко, на секое барање се додава единствен токен, кој се проверува на серверот за автентичност).
Може да се копира од кое било друго успешно барање или од колачиња, каде што е зачувано во полето „JSESSIONID“.
Каде да се најде токенотЗаглавие на друго барање:
Или од колачиња, директно преку конзолата:
Ајде да се обидеме повторно, овој пат ги пренесуваме поставките за преземање, во кои го одредуваме нашиот csrf-токен како параметар во заглавието.
Успех, ги добиваме сите 10 профили. :tada:
Поради разликата во заглавијата, структурата на одговорот е малку поинаква од онаа што е примена во оригиналното барање. Може да ја добиете истата структура ако додадете „Accept: „application/vnd.linkedin.normalized+json+2.1“ на нашиот објект, веднаш до токенот csrf. Пример одговор со додадено заглавие
Потоа можете да го уредите (рачно или автоматизирано) параметарот `start`, покажувајќи на индексот, почнувајќи од кој ќе ни бидат дадени 10 профили (стандардно = 0) од целиот резултат од пребарувањето. Со други зборови, со зголемување за 10 по секое барање, го добиваме вообичаениот излез од страница по страница, 10 профили одеднаш.
Во оваа фаза имав доволно податоци и слобода да продолжам да работам на проектот за миленици. Но, ќе беше грев да не се обидеме да ги прикажеме овие податоци на лице место, бидејќи тие веќе беа при рака. Нема да влеземе во Ембер, кој се користи напред. 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="/mk/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="/mk/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 = () => {
// токен
const csrf = 'ajax:9082932176494192209';
// объект с настройками запроса, передаем токен
const settings = { headers: { 'csrf-token': csrf } }
// урл запроса, с динамическим индексом старта в конце
const url = `https://www.linkedin.com/voyager/api/search/blended?count=10&filters=List(geoRegion-%3Ejp%3A0,network-%3ES,resultType-%3EPEOPLE)&origin=FACETED_SEARCH&q=all&queryContext=List(spellCorrectionEnabled-%3Etrue,relatedSearchesEnabled-%3Etrue)&start=${nextItemIndex}`;
/* делаем запрос, для каждого профиля в ответе вызываем рендер блока, и после инкрементируем стартовый индекс на 10 */
fetch(url, settings).then(response => response.json()).then(data => {
data.elements[0].elements.forEach(createProfileBlock);
nextItemIndex += 10;
});
};
// удаляем все профили из списка
$('.search-results__list').find('li').remove();
// вставляем кнопку загрузки профилей
$('.search-results__list').after('<button id="load-more">Load More</button>');
// добавляем функционал на кнопку
$('#load-more').addClass('artdeco-button').on('click', fetchProfiles);
// ставим по умолчания индекс профиля для запроса
window.nextItemIndex = 0;
Ако го направите ова директно во конзолата на страницата за пребарување, тоа ќе додаде копче што вчитува 10 нови профили со секој клик и ги прикажува во листа. Се разбира, сменете го токенот и URL-то на бараниот пред да го направите ова. Блокот на профилот ќе ги содржи името, позицијата, локацијата, врската до профилот и слика на место.
Заклучок
Така, со минимален напор, успеавме да ја најдеме слабата точка и да си ја вратиме потрагата без ограничувања. Доволно беше да се анализираат податоците и нивниот пат, да се погледне во самото барање.
Не можам да кажам дека ова е сериозен проблем за LinkedIn, бидејќи не претставува никаква закана. Максимумот е изгубен профит поради таквите „заобиколувања“, што ви овозможува да избегнете плаќање за премија. Можеби таков одговор на серверот е неопходен за правилно функционирање на другите делови на страницата, или едноставно е мрзеливост на програмерите и недостаток на ресурси што не дозволува тоа да се направи добро. (Ограничувањето се појави во јануари 2015 година; пред ова немаше ограничување).
PS
Секако, кодот jQuery е прилично примитивен пример за можностите. Во моментов создадов екстензија на прелистувач за да одговараат на моите потреби. Додава контролни копчиња и прикажува целосни профили со слики, копче за покани и општи врски. Плус, динамично собира филтри за локации, компании и други работи и вади токен од колачиња. Така, веќе нема потреба од хардкодирање ништо. Па, додава дополнителни полиња за поставки, а „колку профили да побарате истовремено, до 49“.
Сè уште работам на овој додаток и планирам да го објавам во јавноста. Пиши ако те интересира.