Ошибка скрипта — что вызывает ошибку скрипта и как ее решить

Что такое ошибки сценария?

Ошибки сценария возникают, когда клиентский сценарий нарушает одно и то же происхождение политики браузера пользователя, сделав недопустимый HTTP-запрос между разными источниками.

Если вы работаете на веб-сайте и у вас есть функция Raygun Crash Reporting, подключенная к клиентскому JavaScript, появится сообщение «Ошибка сценария» вероятно, это первое, что вы заметите на своей панели инструментов.

Быстрые ссылки

• Что вызывает ошибки скрипта?
• Что такое длительный скрипт?
• Ошибка скрипта — политика одного происхождения
• Управление политикой одного источника
• Используйте веб-прокси.
• Различное поведение браузера в отношении ошибки сценария

Что вызывает ошибки сценария?

S Ошибки cript, скорее всего, вызваны ошибкой внутри сценария, размещенного в другом домене (например, сценария CDN). В результате браузер пользователя останавливает выполнение сценария, чтобы предотвратить атаку, называемую подделкой межсайтовых запросов. Однако это также может быть проблемой, если сценарий хранится в том же домене, но использует другой порт, протокол (например, http:// вместо https://) или субдомен.

Например, ошибка в скрипте в другом домене может выглядеть так:

 //Файл: https://another-domain.com/index.jsconst a = {}; console.log (abc);  

В вашем домене вызов этого сценария может выглядеть следующим образом. Этот сценарий приведет к отправке в Raygun4JS ошибки сценария.

 //Файл: origin-domain.com/index.html   

Что такое длительный скрипт?

Вы также можете найти ошибку, похожую на ошибку сценария, на панели инструментов Raygun, которая называется «Длительный сценарий». Их имена похожи, но это совершенно разные ошибки, которые нужно обрабатывать по-разному.

Хотя ошибка сценария вызвана нарушением политики одинакового происхождения браузера, длительный сценарий указывает на проблемы с производительностью. В каждом браузере есть временные рамки для выполнения скрипта. Если скрипту требуется больше времени для выполнения, возникнет ошибка «Длительный скрипт». Пользователю также будет представлено диалоговое окно, в котором он может решить, хотят ли они остановить скрипт или продолжать ждать загрузки своего актива..

Ошибка длительного выполнения сценария можно устранить, используя передовые методы кодирования, разбивая сценарии на модули и тщательно проверяя код перед развертыванием в максимально возможном количестве различных условий.

Ошибка сценария. Политика одинакового происхождения

CORS, или совместное использование ресурсов между источниками, — это официальная рекомендация W3C, которая определяет механизм правильного выполнения запросов между источниками на стороне клиента. Политика одного и того же происхождения, применяемая современными браузерами, означает, что скрипты имеют права полного доступа только в том случае, если они загружаются из того же исходного домена, что и исходный документ — когда скрипт проходит проверку CORS.

Что касается архитектуры современных веб-сайтов и приложений, CORS и политика одного происхождения представляют собой проблему. В связи с характером HTTP 1.1 ключевые ресурсы (включая JavaScript) размещаются в доменах, отличных от происхождения, или «сторонних» доменах. В частности, для решения этой проблемы сети CDN используют огромные ресурсы общедоступных облаков, чтобы снизить как затраты, так и время отклика.

Когда код вашего веб-приложения определен и загружен в сценарий, размещенный в домене, отличном от домена один в адресной строке, ошибки, которые попадают в обработчик событий window.onerror , не будут иметь никакой трассировки стека или контекста сообщения для отладки.

Отсутствие трассировка стека не проблема при локальной разработке. Однако отсутствие информации об ошибке становится критической проблемой при попытке выяснить, почему сайт ломается на компьютере пользователя. Это наиболее очевидно, когда Raygun4JS сообщает об этих ошибках, а в группах ошибок отсутствуют какие-либо указания относительно того, что произошло.

Управление политикой одного и того же происхождения

Спецификация и реализация для управления политикой одного и того же происхождения хорошо документирована здесь. Вы заметите, что правильные реализации доступны только в современных браузерах. Подробно см. Различные варианты поведения браузера в конце статьи.

Есть два важных элемента метаданных, которые необходимо включить, чтобы позволить междоменному сценарию пройти проверку CORS в современном браузере. Вам необходимо использовать первый в теге script , который вы добавляете в HTML в исходном домене, а второй — в HTTP-ответе, отправленном сторонним доменом.

1. В исходном домене

Как указано в приведенной выше документации, вам необходимо использовать атрибут crossorigin в соответствующем теге скрипта. Например:

 //Файл: origin-domain.com/index.html   

Без атрибута crossorigin браузеры вообще не используют CORS, что означает, что они предполагают, что запрошенный скрипт размещен в том же источнике и может загружаться без риска для безопасности. Однако, когда они узнают, что сценарий запрашивается из стороннего домена, ваш браузер откажется загрузить его.

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

2. В стороннем домене

Второй важный бит данных — это наличие HTTP-заголовка в ответе стороннего домена, содержащего JavaScript. В частности, заголовок Access-Control-Allow-Origin :

  Access-Control-Allow-Origin: *  

Подстановочный знак в этом примере разрешает межсайтовые запросы к любому сайту. Это подходит для CDN, где сценарий может быть запрошен любым сторонним доменом. Если это частный хост для известного набора доменов, вы можете предоставить этот список вместо подстановочного знака, например:

  Access-Control-  Allow-Origin: http://origin-domain.com  

Вам необходимо реализовать Access-Control-Allow-Origin заголовок ответа на стороннем сервере, откуда исходит внешний скрипт. Как и куда добавить HTTP-заголовок, зависит от типа стороннего сервера.

Например, вот пример кода, который вы можете использовать на сервере Apache. Вы можете добавить его в файл .htaccess . Это позволяет стороннему серверу отправлять все файлы с расширением .js на любой внешний домен.

   Набор заголовков Access-Control-Allow-Origin "*"   

Или, если вы этого не сделаете хотите добавить поддержку CORS только для скриптов, но другие ресурсы, которые могут вам понадобиться, такие как веб-шрифты и CSS, вы можете вместо этого использовать следующий код:

   Набор заголовков Access-Control-Allow-Origin "*"   

Например, вот что я получаю в Chrome 66 без отправки сторонним сервером правильного HTTP-заголовка:

Как видите, браузер не может загрузить внешний скрипт, и в консоли появляется сообщение об ошибке.

После добавления поддержки CORS на сервер, в ответе появляется заголовок Access-Control-Allow-Origin , сторонний скрипт загружается правильно и сообщение об ошибке исчезает с консоли:

Если вы хотите добавить поддержку CORS на другую серверную платформу, есть отличный веб-сайт под названием Enable CORS, который может оказаться полезным. На нем представлены примеры кода и реализации для нескольких различных платформ, таких как IIS , Nginx, Tomcat и др. Кроме того, у более крупных провайдеров CDN, таких как KeyCDN, также часто есть страницы поддержки, на которых объясняется, как можно установить пользовательские HTTP-заголовки на их платформе.

Используйте веб-прокси

Использование веб-прокси — это альтернативный метод, который можно использовать для решения проблемы. Он может быть особенно полезен, если по какой-то причине вы не можете изменить HTTP-заголовок, отправляемый сторонним сервером. Вам необходимо настроить прокси на своем веб-сервере, а затем отправлять запросы Ajax не на сторонний домен, а на веб-прокси, размещенный в том же домене.

Прокси-сервер пересылает данные. запрос к стороннему серверу, получает сценарий и отправляет его обратно на ваш веб-сайт. Таким образом, браузер интерпретирует его как запрос того же происхождения и позволяет вашему фронту nd код для доступа к стороннему скрипту. По сути, веб-прокси функционирует как посредник для ваших запросов с других серверов.

В сети доступны некоторые прокси-серверы CORS с открытым исходным кодом, такие как crossorigin.me или CORS Anywhere. Однако эти сервисы следует использовать только в разработке. Никогда не используйте открытый прокси-сервер CORS на рабочем сайте, они ненадежны и могут представлять серьезную угрозу безопасности.

Различное поведение браузера в отношении ошибки скрипта

В зависимости от того, какой браузер у вас пользователи работают, вышеуказанные свойства могут иметь или не иметь эффекта. Это резюмирует ситуацию на момент написания, относительно поддержки браузером атрибута crossorigin и CORS:

• Chrome 30+
• Firefox 13+
• Opera 12.50+
• Safari (минимум 6+)
• Edge 0.10 +

В этих браузерах, если присутствует тег script , также должен присутствовать HTTP-заголовок. В противном случае сценарий будет заблокирован.

Firefox имеет дополнительное поведение для ошибок времени выполнения. Они будут предоставлены window.onerror независимо от двух свойств. Это не угроза безопасности. Однако синтаксические ошибки будут заблокированы как в браузерах Gecko, так и в браузерах WebKit, если присутствует атрибут crossorigin , но связанный домен с перекрестным происхождением не имеет заголовка.

Internet Explorer

Об ошибках будут сообщаться со всеми доступными данными в IE 10 и ниже. Теперь это считается проблемой безопасности.

Internet Explorer 11+

Сторонние ошибки не будут содержать никаких данных, а атрибуты не соблюдаются на момент написания.

Готовы устранить ошибки скрипта?

Raygun Crash Reporting выявляет ваши ошибки скрипта за вас. Узнайте, о чем идет речь, и начните бесплатную 14-дневную пробную версию.

Ошибка скрипта: судебная экспертиза JavaScript

Главная страница блога »

Скрипт Ошибка: заклятый враг мониторинга ошибок JavaScript. Как только вы начинаете отслеживать проблемы на стороне клиента, они всплывают. Он скрывает истинную природу ваших ошибок во внешнем интерфейсе своей завесой неизвестности. Вам нужно будет разобраться с этим, если вам нужно комплексное решение для отслеживания ошибок во внешнем интерфейсе.

Анализ

Ошибка сценария является признаком нарушения политики одного источника в браузере.

Политика одного источника ограничивает способ загрузки документа или сценария из одного источника может взаимодействовать с ресурсом из другого источника. Политика одинакового происхождения используется как средство предотвращения некоторых атак с подделкой межсайтовых запросов.

Когда ваше веб-приложение загружает JavaScript файла из другого источника, этот сценарий подчиняется ограничениям Политики одинакового происхождения. Ограничения включают в себя обфускацию ошибок при отображении ошибки глобальным слушателям: window.onerror и window.addEventListener ('error') .

Эта политика браузера направлена ​​на предотвращение утечки информации между доменами, которая может допускать атаки подделки межсайтовых запросов. Политика применяется в всех соответствующих браузерах , включая все версии Chrome, Firefox, Safari, Opera и Internet Explorer.

Например, допустим, ваше приложение записывает ошибки из window.onerror и загружает AngularJS, размещенный на CDN. Всякий раз, когда из Angular генерируется ошибка, она записывается как просто Script Error без упоминания исходного сообщения, файла angular.js или трассировки стека.

Подумайте, как Chrome выявляет ошибку JavaScript. Когда происходит ошибка, он оценивает источник безопасности файла. Если это нарушает политику, ошибка просто перезаписывается пустыми значениями.

 bool ScriptExecutionContext :: dispatchErrorEvent (const String & errorMessage, int lineNumber, const String & sourceURL) {... if (securityOrigin ()  -> canRequest (targetUrl)) {сообщение = errorMessage;  line = lineNumber;  sourceName = sourceURL;  } else {message = "Ошибка сценария.";  sourceName = String ();  строка = 0;  } ... RefPtr  errorEvent = ErrorEvent :: create (сообщение, имя источника, строка);  target-> dispatchEvent (errorEvent);  ...} 

Даже если ошибка JavaScript запутана политикой одного и того же происхождения, отладчик Chrome отобразит исходную информацию об ошибке. Поэтому вы можете не знать, что ошибки маскируются, пока вы не начнете их отслеживать.

Вы можете столкнуться с Script Error , если загрузите хотя бы один ресурс JavaScript из другой домен, например CDN или сторонний. Обратите внимание, что сценарий может быть загружен JavaScript во время выполнения, поэтому вам нужно будет проверить сетевые запросы в отладчике, чтобы быть уверенным.

Решение

Мы можем обойти политику одинакового происхождения с помощью совместного использования ресурсов между источниками (CORS). CORS чаще всего используется для устранения другого нарушения политики одного и того же происхождения: разрешения междоменных вызовов AJAX к внешним API. Его также можно использовать для загрузки ресурсов JavaScript, освобожденных от обфускации ошибок.

Каждый сервер, CDN или поставщик, с которого вы загружаете ресурсы JavaScript, должен обслуживать запрос с заголовками CORS:

 Access-Control-Allow-Origin: ВАШ_ДОМЕН |  * 

Подстановочный знак * можно использовать вместо домена, если вы хотите разрешить загрузку файла из любого места. Существуют фантастические ресурсы о том, как настроить ваш веб-сервер для добавления этих заголовков, и у большинства CDN и поставщиков есть механизм для их настройки или запроса. Из своего веб-приложения вы можете указать браузеру загружать файлы CORS JavaScript с атрибутом crossorigin :

По умолчанию ресурс будет запрашиваться анонимно. Если вы хотите использовать проверку подлинности CORS, вы также можете указать учетные данные для загрузки ресурса.

Загрузка ресурсов с помощью CORS поддерживается в большинстве современных браузеров. Однако отсутствие поддержки Internet Explorer вызывает беспокойство, особенно из-за большого количества ошибок, связанных только с IE, с которыми мы часто сталкиваемся.

Браузер	Версии	Поддержка загрузки CORS
Chrome	30+
Firefox	13+
Safari	7+
Opera	12.5+
Internet Explorer	Н/Д
Microsoft Edge	Н/Д

Загрузка CORS определенно стоит того, чтобы получить дополнительный контекст, который вы получите от большинства браузеров. В неподдерживаемых браузерах по-прежнему полезно отслеживать Script Error , чтобы вы знали, какие браузеры, страницы и пользователи имеют проблемы.

Конечно, если вы просто не делаете этого. не волнуйтесь, вы должны игнорировать их и уменьшить шум.

TrackJS лучше фиксирует информацию об ошибках JavaScript, даже в Internet Explorer. Он имеет более глубокую проверку DOM, чтобы собрать больше информации об ошибках и событиях, которые привели пользователя к проблемам. Начните с бесплатной пробной версии сегодня и исправьте другие ошибки.

Тодд Х. Гарднер

Генеральный директор и соучредитель