Giới hạn
Có một hạn chế như vậy trên LinkedIn - . Rất có thể bạn cũng như tôi cho đến gần đây, chưa từng gặp hoặc nghe nói đến nó.
Bản chất của giới hạn là nếu bạn sử dụng tính năng tìm kiếm những người bên ngoài danh bạ của mình quá thường xuyên (không có số liệu chính xác, thuật toán sẽ quyết định dựa trên hành động của bạn - tần suất và số lượng bạn đã tìm kiếm, thêm người), thì kết quả tìm kiếm sẽ xuất hiện sẽ bị giới hạn ở ba hồ sơ, thay vì 1000 (mặc định 100 trang, 10 hồ sơ mỗi trang). Giới hạn được đặt lại vào đầu mỗi tháng. Một cách tự nhiên, .
Nhưng cách đây không lâu, đối với một dự án thú cưng, tôi bắt đầu chơi rất nhiều với tìm kiếm LinkedIn và đột nhiên gặp phải hạn chế này. Đương nhiên, tôi không thích điều này lắm, vì tôi không sử dụng nó cho bất kỳ mục đích thương mại nào nên suy nghĩ đầu tiên của tôi là nghiên cứu những hạn chế và cố gắng khắc phục nó.
[Một điều cần làm rõ quan trọng: các tài liệu trong bài viết chỉ được trình bày cho mục đích thông tin và giáo dục. Tác giả không khuyến khích việc sử dụng chúng cho mục đích thương mại.]
Chúng tôi đang nghiên cứu vấn đề
Chúng tôi có: thay vì mười hồ sơ có phân trang, tìm kiếm chỉ trả về ba hồ sơ, sau đó một khối có “đề xuất” của tài khoản trả phí được chèn vào và bên dưới là các hồ sơ mờ và không thể nhấp vào.
Ngay lập tức, bàn tay đưa ra bảng điều khiển dành cho nhà phát triển để xem các cấu hình ẩn này - có lẽ chúng ta có thể loại bỏ một số kiểu làm mờ hoặc trích xuất thông tin từ một khối trong đánh dấu. Nhưng, thật đáng ngạc nhiên, những hồ sơ này chỉ là và không có thông tin nào được lưu trữ.
Được rồi, bây giờ chúng ta hãy xem tab Mạng và kiểm tra xem các kết quả tìm kiếm thay thế chỉ trả về ba cấu hình có thực sự hoạt động hay không. Chúng tôi tìm thấy yêu cầu mà chúng tôi quan tâm đối với “/api/search/blend” và xem phản hồi.
Các hồ sơ nằm trong một mảng `included`, nhưng đã có 15 thực thể trong đó. Trong trường hợp này, ba đối tượng đầu tiên trong số đó là các đối tượng có thông tin bổ sung, mỗi đối tượng chứa thông tin về một hồ sơ cụ thể (ví dụ: liệu hồ sơ đó có cao cấp hay không ).
12 hồ sơ tiếp theo là hồ sơ thực - kết quả tìm kiếm, trong đó chỉ có ba hồ sơ sẽ được hiển thị cho chúng tôi. Như bạn có thể đoán, nó chỉ hiển thị những người nhận được thông tin bổ sung (ba đối tượng đầu tiên). Ví dụ: nếu bạn lấy câu trả lời từ một hồ sơ không có giới hạn, bạn sẽ nhận được 28 thực thể - 10 đối tượng bổ sung. thông tin và 18 hồ sơ.
Trả lời hồ sơ không giới hạn
Tại sao có hơn 10 hồ sơ đến, mặc dù chính xác là 10 hồ sơ được yêu cầu và chúng không tham gia hiển thị theo bất kỳ cách nào, ngay cả trên trang tiếp theo chúng cũng sẽ không xuất hiện - tôi vẫn chưa biết. Nếu phân tích URL yêu cầu, bạn có thể thấy số lượng đó=10 (có bao nhiêu hồ sơ cần trả về trong phản hồi, tối đa là 49).
Tôi rất vui khi nhận được bất kỳ ý kiến về vấn đề này.
Hãy thử nghiệm
Được rồi, điều quan trọng nhất hiện nay chúng ta biết chắc chắn là có nhiều hồ sơ trong phản hồi hơn những gì chúng hiển thị cho chúng ta. Điều này có nghĩa là chúng tôi có thể nhận được nhiều dữ liệu hơn, bất chấp giới hạn. Hãy thử tự mình lấy API, trực tiếp từ bảng điều khiển, bằng cách sử dụng tìm nạp.
Đúng như dự đoán, chúng tôi gặp lỗi 403. Điều này là do bảo mật, ở đây chúng tôi không gửi mã thông báo CSRF (. Tóm lại, một mã thông báo duy nhất được thêm vào mỗi yêu cầu, được kiểm tra tính xác thực trên máy chủ).
Nó có thể được sao chép từ bất kỳ yêu cầu thành công nào khác hoặc từ cookie, nơi nó được lưu trữ trong trường 'JSESSIONID'.
Nơi tìm mã thông báoTiêu đề của một yêu cầu khác:
Hoặc từ cookie, trực tiếp qua bảng điều khiển:
Hãy thử lại, lần này chúng tôi chuyển cài đặt để tìm nạp, trong đó chúng tôi chỉ định mã thông báo csrf của mình làm tham số trong tiêu đề.
Thành công, chúng ta nhận được đủ 10 hồ sơ. :tada:
Do sự khác biệt về tiêu đề, cấu trúc của phản hồi hơi khác so với cấu trúc nhận được trong yêu cầu ban đầu. Bạn có thể có cấu trúc tương tự nếu bạn thêm ‘Accept: ‘application/vnd.linkedin.normalized+json+2.1’ vào đối tượng của chúng tôi, bên cạnh mã thông báo csrf.
Phản hồi mẫu có tiêu đề được thêm vào
Cái gì tiếp theo?
Sau đó, bạn có thể chỉnh sửa (thủ công hoặc tự động hóa) tham số `start`, trỏ đến chỉ mục, bắt đầu từ đó chúng ta sẽ được cung cấp 10 hồ sơ (mặc định = 0) từ toàn bộ kết quả tìm kiếm. Nói cách khác, bằng cách tăng nó lên 10 sau mỗi yêu cầu, chúng tôi sẽ nhận được kết quả đầu ra theo từng trang thông thường, 10 hồ sơ cùng một lúc.
Ở giai đoạn này, tôi đã có đủ dữ liệu và tự do để tiếp tục thực hiện dự án thú cưng. Nhưng sẽ là một tội lỗi nếu không cố gắng hiển thị dữ liệu này ngay tại chỗ vì nó đã có sẵn trong tay. Chúng tôi sẽ không đi vào Ember, được sử dụng ở phía trước. jQuery đã được kết nối với trang web và sau khi tìm hiểu kiến thức về cú pháp cơ bản trong bộ nhớ, bạn có thể tạo nội dung sau trong vài phút.
mã 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="/vi/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="/vi/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;
Nếu bạn thực hiện việc này trực tiếp trong bảng điều khiển trên trang tìm kiếm, nó sẽ thêm một nút tải 10 cấu hình mới với mỗi lần nhấp và hiển thị chúng trong danh sách. Tất nhiên, hãy thay đổi mã thông báo và URL thành mã được yêu cầu trước khi thực hiện việc này. Khối hồ sơ sẽ chứa tên, vị trí, vị trí, liên kết đến hồ sơ và hình ảnh giữ chỗ.
Kết luận
Vì vậy, với nỗ lực tối thiểu, chúng tôi đã có thể tìm ra điểm yếu và lấy lại khả năng tìm kiếm mà không bị hạn chế. Chỉ cần phân tích dữ liệu và đường dẫn của nó, xem xét chính yêu cầu là đủ.
Tôi không thể nói rằng đây là một vấn đề nghiêm trọng đối với LinkedIn vì nó không gây ra bất kỳ mối đe dọa nào. Lợi nhuận bị mất tối đa do những "cách giải quyết" như vậy, cho phép bạn tránh phải trả phí bảo hiểm. Có lẽ phản hồi của máy chủ như vậy là cần thiết để các phần khác của trang web hoạt động chính xác hoặc đơn giản là sự lười biếng của các nhà phát triển và thiếu tài nguyên không cho phép thực hiện tốt. (Giới hạn xuất hiện vào tháng 2015 năm XNUMX; trước đó không có giới hạn).
PS
Đương nhiên, mã jQuery là một ví dụ khá nguyên thủy về các khả năng. Hiện tại tôi đã tạo một tiện ích mở rộng cho trình duyệt phù hợp với nhu cầu của mình. Nó thêm các nút điều khiển và hiển thị hồ sơ đầy đủ bằng hình ảnh, nút mời và các kết nối chung. Ngoài ra, nó còn tự động thu thập các bộ lọc cho vị trí, công ty và những thứ khác, đồng thời truy xuất mã thông báo từ cookie. Vì vậy, không cần phải mã hóa bất cứ điều gì nữa. Chà, nó bổ sung thêm các trường cài đặt bổ sung, chẳng hạn như “có bao nhiêu hồ sơ cần yêu cầu cùng một lúc, tối đa 49”.
Tôi vẫn đang nghiên cứu phần bổ sung này và có kế hoạch phát hành nó ra công chúng. Viết nếu bạn quan tâm.
Nguồn: www.habr.com