Коли я повинен використовувати атрибут "crossorigin" на "попередньому з'єднанні" <посилання>?


14

Я хотів би включити на свій сайт деякі підказки щодо попереднього підключення, щоб браузери могли (наприклад) підключатися до jQuery CDN до того, як вони насправді побачать тег сценарію, який викликає CDN. Я не впевнений, чи повинен я включати атрибут "crossorigin" або яким має бути його значення. Специфікації кажуть, зокрема,

Щоб ініціювати попереднє з'єднання, агент користувача повинен виконати наступні дії:

[…]

  1. Нехай corsAttributeState - поточний стан crossoriginатрибута вмісту елемента .
  2. Нехай облікові дані - булеве значення, встановлене на true.
  3. Якщо corsAttributeState є, Anonymousа походження не дорівнює поточному походження документа, встановіть облікові дані на false.
  4. Спроба встановити зв'язок із походженням та обліковими даними .

Я не знаю, як інтерпретувати цей алгоритм. Якщо я попередньо підключився до CDN, що дозволить кожному завантажувати його вміст без будь-яких даних, які значення я повинен використовувати для атрибута "crossorigin"?


Відповіді:


4

Я шукав те саме, і знайшов це

Тут зазначається, що якщо ви не використовуєте атрибут cross origin, агент користувача просто здійснює пошук dns, але не встановлює зв’язок із конкретним доменом. Тому атрибут crossorigin потрібен, якщо вам потрібно попередньо підключитися до перехрещення домену, як-от так:

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>

Крім того, якщо ви хочете надіслати деякі облікові дані для цього конкретного крос-домену, ви можете встановити значення crossorigin, оскільки в crossorigin = use-credentialsіншому випадку я думаю, що значення за замовчуванням є анонімним.


Це напівправда. Якщо використовується CORS (як і у шрифтах), із запитом шрифту використовуватиметься лише пошук DNS . (З'єднання все ще відбувається, але воно не відображається на графіку водоспаду, тому що для запиту CORS потрібно відкрити окреме з'єднання .) Якщо ви отримуєте сценарій, використовуючи crossoriginаналогічно, тратите з'єднання, оскільки потрібно відкрити нове з'єднання, не використовує CORS.
Майкл Креншо

2

Поки я розумію використання crossorigin, особливо з точки зору його значень, anonymousі use-credentialsвам слід користуватися crossorigin="use-credentials"у випадку:

  • ви використовуєте ресурси, як-от зображення чи відео, які мають атрибут crossorigin
  • ви плануєте переносити файли cookie, HTTP-аутентифікацію та сертифікати SSL на стороні клієнта між джерелами, виходячи з попередніх взаємодій агента користувача з початком.

На додачу до цитованої вами документації я отримав це і те . Але дійсно документація вводить в оману і містить неправильні написання: перший називає її use-credentials, другий - user-credentials.

У будь-якому розумінні:

  • взагалі немає crossoriginрівнихcrossorigin="anonymous"
  • crossorigin дорівнює crossorigin="use-credentials"

Можливо, хтось мене виправить.

PS : Поточна версія сторінки Mozilla до теми означає:

Недійсне ключове слово та порожній рядок будуть оброблятися як анонімне ключове слово.

Значить: взагалі немає crossorigin, crossoriginабо crossorigin="use_credentials"всі розглядаються як crossorigin="anonymous".


5
Я вважаю, як згадується в MDN , за замовчуванням (тобто, коли атрибут не вказаний), CORS взагалі не використовується. Крім того, встановлення crossoriginдорівнює лише crossorigin="anonymous".
Шекспір

1

Це залежить від двох речей:

  1. Тип активів для завантаження (який визначає, чи буде використовуватися CORS)
  2. Чи використовує цільовий сервер облікові дані для підключень CORS

Для jQuery ви б не використовувалиcrossorigin . Сценарії не належать до типів ресурсів, якими браузери використовують CORS для завантаження .

З іншого боку, шрифти використовують CORS.

  • Якщо сторінка буде отримувати лише ресурси, які використовують CORS, включіть crossoriginатрибут.
  • Якщо сторінка отримуватиме лише ресурси, які не використовують CORS, опустіть crossorigin. Якщо
  • Якщо сторінка отримає обидва види ресурсів, вам можуть знадобитися два підказки щодо ресурсів . (Повне розкриття, посилання на мій особистий сайт. :-)) Хтось зазначив, що вам можуть не знадобитися два підказки для HTTP / 2. Я не встиг випробувати.

Ось повідомлення про переповнення стека, де я зіткнувся з тією ж проблемою.

Я не заглиблювався, коли необхідні облікові дані CORS. Я не бачив прикладу, де вони потрібні, тому, швидше за все, ви в безпеці crossorigin(тобто `crossorigin =" анонімний ").


1

Усі відповіді поки що здаються або спрощеними, неповними або частково неправильними (тема складна, речі названі в оманах і недостатньо задокументовані!), Тож ось моє розуміння:

Щоб мати можливість повторно використовувати з'єднання, створене компанією <link rel=preconnect>, все залежить від того, який вміст ви хочете отримати, звідки, чи надсилатиме запит облікові дані браузера (які браузер може встановлювати явно або неявно):

Запит того самого походження ( example.comзапитує субресурс від example.com)

В preconnectпершу чергу немає потреби в цьому; браузер тримає з'єднання відкритим після завантаження сторінки досить довго. Якщо необхідно відкрити кілька з’єднань, браузер самостійно вирішує, чи і скільки їх відкрити (залежно від того, якщо сервер оголошує підтримку HTTP / 2 в рукостисканні TLS, налаштуваннях браузера тощо)

щоб перевірити : що, якщо запит того самого походження має crossoriginатрибут: він використовується чи ігнорується?

Запит перехресного походження ( example.comзапитує субресурс від another.com)

  • якщо фактичний запит має crossoriginатрибут, явно встановлений у HTML ( crossOriginу JS - важливий випадок), попередній зв’язок також повинен мати його з однаковим значенням (можливо, за винятком випадків, коли він не має сенсу і crossoriginігнорується - не повністю зрозумілий для мені ще)
  • інше, якщо запит, якщо для <script type=module>: перевірити
  • інакше, якщо запит і «стара школа» запит <img>, <style type=stylesheet>, <iframe>, класичний і <script>т.д. (ініційовані з допомогою HTML або JS) без crossoriginявно зазначеного , то preconnect не повинен мати crossoriginнабір атрибутів.
  • в іншому випадку, якщо запит є запитом шрифту перехресного походження , попереднє з'єднання повинно матиcrossorigin=anonymous
  • інше, якщо запит має поперечне походження fetch або XHR:
    • якщо це робиться в авторизованому режимі (тобто файли cookie приєднуються або використовується основний auth HTTP; у випадку вилучення це означає credentials !== omit; у випадку XHR withCredentials === true:): попереднє з'єднання повинно матиcrossorigin=use-credentials
    • якщо він не перебуває в обліковому режимі: попереднє підключення повинно мати crossorigin=anonymous

Для останнього випадку (fetch / XHR) перейдіть до мережевої панелі в розробниках Chrome / Firefox, клацніть правою кнопкою миші запит і виберіть copy as fetchзі спадного меню. Це створить фрагмент JS, який підкаже вам, чи цей запит увімкнено CORS ( "mode"=="cors") та підтверджено ( "credentials"=="include"|"same-origin").

Зверніть увагу , однак трюк вище не працює для не-XHR / вибірок запитів, тому що, наприклад , fetchі <img>використовують різні алгоритми для встановлення з'єднання, як описано раніше.

Нарешті, в HTML, <link ...crossorigin>=== <link ...crossorigin=anonymous>.

Додаткові примітки та посилання:

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.