По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
CORS – это механизм браузера, который позволяет серверам указывать сторонние источники, которые имеют право запрашивать у них ресурсы. Этот механизм обеспечивает безопасность и не дает вредоносным сайтам красть данные, которые принадлежат другим источникам.
CORS расшифровывается как Cross-Origin Resource Sharing, что переводится как «обмен ресурсами с запросом происхождения». В случае, когда для загрузки ресурса используется CORS, браузер отправляет предварительный HTTP-запрос
OPTIONS
. Сервер должен ответить, указав все источники, с которыми он собирается взаимодействовать. Также он может определить дополнительные ограничения, например, указать HTTP-заголовки, которые могут быть отправлены.
Браузер проверяет текущий источник и исходящий запрос на соответствие спецификациям сервера. Если все проверки были пройдены успешно, то запрос одобряется. В противном случае запрос будет отклонен. Если это произойдет, вы увидите предупреждение в консоли.
Когда используется CORS
Браузеры применяют CORS для запросов Ajax и Fetch. Этот механизм также используется для веб-шрифтов, текстур WebGL и отрисовки изображения холста с помощью
drawImage()
. CORS также потребуется для любого правомерного запроса к стороннему источнику.
CORS не применяется в том случае, если запрос рассматривается как «простой». Простой запрос должен начинаться с
GET
,
HEAD
или
POST
и иметь тип содержимого
text/plain
,
application/x-www-form-urlencoded
или
multipart/form-data
. Единственные заголовки простых запросов, которые допускаются, - это
Accept
,
Accept-Language
,
Content-Language
и
Content-Type
.
Если запрос не соответствует всем критериям, которые мы перечислили выше, то современные браузеры запускают CORS. Важно понимать, что CORS – это технология для браузера, и вы не сможете использовать его при самостоятельной отправке запросов, например, с помощью утилиты
curl
в своем терминале.
CORS не всегда отправляет предварительный запрос
OPTIONS
. Предварительная проверка нужна и используется только тогда, когда запрос может вызвать «побочные эффекты» на сервере. Как правило, это относится ко всем методам запроса, кроме
GET
.
Предположим, что есть запрос
POST
к
/api/users/create
. Сервер всегда будет создавать нового пользователя, но при этом браузер может отказать в доступе к ответу на этот запрос, если для запроса был использован CORS. Есть шанс, что сервер может отклонить реальный запрос, если перед этим был отправлен запрос
OPTIONS
. Это обеспечивает то, что учетная запись пользователя на самом деле не будет создаваться.
Управление CORS на стороне клиента
Несмотря на то, что CORS является технологией для браузера, вы все равно не можете влиять на нее напрямую с помощью клиентского кода. Это гарантирует, что вредоносные скрипты не смогут обойти защиту CORS, чтобы загрузить данные со сторонних доменов.
CORS, как правило, незаметен, поэтому вы даже не будете знать о том, что он работает. Если в процессе CORS произойдет сбой, то ваш код JavaScript увидит обычную сетевую ошибку. Получить точную информацию о том, что пошло не так, невозможно, поскольку это может представлять риск нарушения безопасности. Все подробности записываются в консоль.
Единственный способ устранить сбои CORS – это убедиться, что ваш сервер отправляет корректные заголовки ответов. Теперь давайте посмотрим, как это делается.
Управление CORS на стороне сервера
Для начала вам следует убедиться в том, что ваш сервер правильно обрабатывает запросы
OPTIONS
. Возможно, вам придется создать новый маршрут обработки запросов в вашей веб-среде. В большинстве случаев вам придется принимать запросы
OPTIONS
к каждой конечной точке, которая может получить CORS-запрос от браузера. Ответ не обязательно должен иметь тело, но он должен включать в себя определенные заголовки, которые сообщают браузеру, что делать дальше.
Начните с заголовка
Access-Control-Allow-Origin
. Он укажет на сторонний источник, который имеет право взаимодействовать с вашей конечной точкой. Указать можно только один источник; но вы можете обрабатывать несколько источников, динамически устанавливая в качестве значения заголовка источник, из которого был отправлен запрос. Текущий источник можно найти в заголовке запроса
Origin
.
Access-Control-Allow-Origin
принимает * в качестве специального подстановочного символа. Это позволит принимать запросы CORS из всех источников. Здесь следует быть осторожным, поскольку указание разрешенных источников обеспечивает контроль и не дает вредоносным скриптам запрашивать данные с вашего сервера.
Access-Control-Allow-Origin
должен быть включен в ответ вашего сервера на реальный запрос и в ответ на запрос
OPTIONS
. После того, как этот заголовок будет настроен, будет разрешен базовый обмен данными со сторонним клиентом браузера.
Указание CORS-заголовков
CORS-запросы, как правило, поддерживают только заголовки «простых» запросов, которые были перечислены выше. Если вы хотите использовать какой-то другой заголовок, например,
Authorization
или настраиваемый заголовок, то вашему серверу необходимо будет явно разрешить его в ответе на предварительный запрос.
Установите заголовок
Access-Control-Allow-Headers
. Его значение – это список названий заголовков через запятую, которые будут приняты с реальным запросом.
Access-Control-Allow-Headers: Authorization, X-Custom-Header
Теперь браузер разрешит запросы с заголовками
Authorization
или
X-Custom-Header
.
Браузер отправляет заголовок
Access-Control-Allow-Headers
вместе с предварительным CORS-запросом. Он содержит список заголовков, которые будут отправлены с реальным запросом. Ваш серверный код может использовать эту информацию для того, чтобы понять, как нужно ответить на предварительный запрос.
Ограничение на определенные методы запроса
Аналогично тому, как мы указываем заголовки запроса, так и конечные точки сервера могут определять, какие HTTP-методы из различных источников будут разрешены. Установите заголовок
Access-Control-Allow-Methods
. Его значение – список названий методов через запятую.
Access-Control-Allow-Methods: GET, POST, DELETE
Браузер отправляет заголовок
Access-Control-Request-Method
с предварительным запросом. Таким образом сервер узнает HTTP-метод, который будет использоваться для выполнения окончательного запроса.
Cookie-файлы и учетные данные
CORS-запросы, как правило, не отправляют cookie-файлы, так как в них может содержаться конфиденциальные учетные данные, которые идентифицируют отправителя. Если вам необходимо добавить cookie-файл к запросу на другой источник, то это нужно явно разрешить в клиентском коде:
fetch("https://localhost/demo", {
mode: "cors",
credentials: "include"
});
К тому же сервер должен установить заголовок ответа
Access-Control-Allow-Credentials: true
, чтобы сообщить о том, что он соглашается на обмен cookie-файлами, которые содержат учетные данные.
Если вы используете заголовок
Access-Control-Allow-Credentials
, то нельзя использовать подстановочный символ (*) в заголовке
Access-Control-Allow-Origin
. Сервер должен явно указать источник для того, чтобы обезопасить конфиденциальность пользователя. Если вы будете использовать подстановочный символ, то браузер не выполнит запрос и вернет ошибку.
Предварительное кэширование
Предварительные запросы
OPTIONS
усиливают нагрузку на каждый запрос, который вы отправляете. При хорошем соединении задержка должна быть почти незаметной, и все же нерационально вызывать одну и ту же конечную точку раз за разом.
Вы можете указать браузеру кэшировать ответы на предварительные запросы. Для этого вам нужно установить заголовок
Access-Control-Max-Age
. Значение этого заголовка – это время, выраженное в секундах. В течение этого времени браузер может хранить кэшированный ответ. Последующие запросы к той же конечной точке в течении заданного периода времени не будут сопровождаться предварительными запросами.
Заключение
При первом знакомстве с технологией CORS она может сбивать с толку. Эта технология браузера, которая контролируется ответами сервера. Использование CORS неизбежно, но при этом оно может оказаться неуправляемым, если у вас нет доступа к серверному коду, с которым вы взаимодействуете.
Фактическая реализация CORS довольно проста. Убедитесь, что ваш API или CDN отправляет корректные заголовки ответов, в особенности это касается заголовка
Access-Control-Allow-Origin
. Если с этим проблем нет, то у вас будет безопасная связь между источниками, которая поможет избежать вмешательства злоумышленников.
Процесс русификации интерфейса FusionPBX не является трудоемким, но, для русификации вам скорее всего придется переустановить FusionPBX с нуля - дело в том, что разработчики добавили русский перевод только в master ветку, а не в stable.
Русификация
Поэтому перед запуском установочного скрипта FusionPBX (как это делается, вы можете ознакомиться в нашей статье), необходимо провести некоторые манипуляции с ним:
Открыть файл любым текстовым редактором по пути usr/src/fusionpbx-install.sh/centos/resources/config.sh - мы будем использовать vim.
vim usr/src/fusionpbx-install.sh/centos/resources/config.sh
Далее строчку system_branch нужно поменять на master и запустить скрипт, как описано в нашей статье.
После установки необходимо зайти в веб-интерфейс, в раздел Home → Account Settings и в поле Language выбрать Russian [ru-ru].
Следующим шагом переходим в Advanced → Menu Manager, кликаем на иконку карандаша справа и меняем установку языка на ru-ru:
После чего необходимо перейти в раздел Advanced → Upgrade, выбрать сброс настроек меню (как на скриншоте ниже) и нажать Execute:
После чего необходимо будет перезайти в веб-интерфейс и вы должны будете увидеть его на русском!
Всем привет! Сейчас мы расскажем об основных правилах, которые следует соблюдать при удаленном подключении телефона к IP-АТС. Актуально не только для Asterisk, но и для вообще любых IP-АТС.
Основные проблемы возникают из-за 3 факторов: Недостаточная пропускная способность сети, конфигурация межсетевых экранов и функционал инспектирования SIP-трафика. Но обо всём по порядку.
Пропускная способность (Bandwidth)
Давайте посчитаем, какая нам потребуется пропускная способность для одного звонка с использованием кодека G.711. При условии, что мы передаём голос в стандартной Ethernet – сети и будет задействован стек протоколов – IP/UDP/RTP :
По умолчанию, кодек G.711 формирует два голосовых семпла общей длительностью 20 мс, размер которых = 160 байт. Скорость потока, создаваемого G.711 = 64 Кбит/c
Заголовки канального уровня (Layer 2) потребуют ещё 18 байт
Заголовки сетевого уровня (IP - Layer 3) добавят ещё 20 байт
Далее заголовки UDP – ещё 8 байт
Наконец, RTP потребует 12 байт
Таким образом, общий размер пакета, в котором будет передаваться 20 мс голоса составит: 160 + 18 + 20 + 8 + 12 = 218 байт
Количество пакетов в секунду, формируемых G.711 = скорость потока кодека / размер голосовой нагрузки (сэмплов) = 64000 бит/c / (160 байт * 8 бит на байт) = 50 пакетов в секунду
Теперь мы можем посчитать полосу пропускания, необходимую для передачи 50 пакетов, содержащих 20 мс голоса, которые будут передаваться по сети. Полоса пропускания = 218 байт * 8 бит на байт * 50 = 87200 бит/с = 87.2 Кбит/c.
Рекомендуется ещё закладывать 5% в качестве защитного интервала: 87.2 * 1.05 = 91.56 Кбит/с
Вот примерно такой должна быть полоса пропускания интернет соединения со стороны подключения удалённого телефона, и на стороне IP-АТС. Если у одной из сторон будет медленное соединение, то качество голоса будет неудовлетворительным.
Зная параметры VoIP сети и используемого кодека, Вы без проблем сможете вычислить необходимую Вам полосу пропускания. Чтобы больше узнать про кодеки, рекомендуем почитать нашу статью.
Телефонный звонок – это симметричное соединение. Поэтому необходимо иметь минимум 91.56 Кбит/с как для входящего трафика (download speed), так и для исходящего (upload speed). Если удалённый пользователь имеет 10 Мб на скорость скачивания (download), то это ещё не значит, что он имеет сколько же на upload.
Но даже если наш удалённый пользователь будет иметь 10 Мб на скачивание и 512 Кбит на загрузку, это ещё не гарантирует нормальное VoIP соединение. Потому что полоса пропускания будет делиться между всеми активностями, которые пользователь совершает в Интернете. Догадайтесь - что будет, если наш пользователь находится в телефонном звонке, а кто-то в его сети начнёт скачивать тяжёлый файл или смотреть онлайн видео? При скачивании файлов задержка или потеря пакета может быть даже не заметна. А вот VoIP трафик передаётся в реальном времени и он очень чувствителен к задержкам и потерям пакетов. Любой из этих факторов может привести к срыву звонка.
Если Вы столкнулись с такой проблемой, рекомендуем настроить Quality of Service или Traffic Shaping. Данный функционал позволяет раздать приоритеты разным видам трафика на маршрутизаторе. Более подробно о механизме QoS можно почитать в нашей статье. А здесь примеры настройки на маршрутизаторе Mikrotik.
Межсетевой экран (Firewall)
Необходимо точно понимать, что удалённый телефон – это телефон, который подключается к Вашей IP-АТС не напрямую. Он не находится в Вашей локальной сети (LAN) и, что ещё важнее, он не находится в Вашей виртуальной локальной сети (VPN). Поэтому, для его корректной работы, нужно будет открыть кое какие порты на роутере или межсетевом экране.
5060 - По стандарту именно этот UDP порт используется протоколом SIP для обмена сигнальной информацией.
10000 – 20000 - (В большей степени актуально для Asterisk). UDP порты используются протоколом RTP и RTCP для передачи исходящего и приема входящего аудио трафика. Если вы столкнулись с проблемой односторонней слышимости или полным её отсутствием (при условии наличия сигнализации SIP) – скорее всего, дело в RTP портах на одной из сторон соединения.
69 TFTP / 21 FTP - Порты для обмена файлами. В IP-АТС используются для автоматической настройки и обновления телефонных аппаратов при помощи функции auto-provision.
Отнеситесь данному пункту очень серьёзно. Нельзя просто открывать эти порты всему миру. Необходимо также настроить правила, чтобы доступ к этим портам могли получить только доверенные устройства.
Если Вы используете Asterisk/FreePBX, то рекомендуем более подробно узнать какие ещё порты может понадобиться открыть вот тут.
Функционал испектирования SIP
SIP ALG (Application Layer Gateway) – это функционал, который испектирует SIP трафик, который проходит через маршрутизатор и позволяет модифицировать его так, чтобы не нужно было делать проброс портов для SIP и RTP.
Зачастую, администраторы, которые настраивают удалённый телефон для подключения к IP-АТС, сталкиваются именно с проблемами включенного на маршрутизаторе SIP ALG. Дело в том, что SIP ALG может изменить сигнальные пакеты так, что АТС не сможет их распознать и телефон не сможет нормально зарегистрироваться. Поэтому если Вы столкнулись с проблемой подключения телефона, рекомендуем также обратить внимание на функционал SIP ALG Вашего маршрутизатора.
Многие производители включают его по умолчанию. Мы же рекомендуем либо правильно настроить его в соответствии с инструкцией от производителя, либо, если никаких других вариантов не осталось – отключить его.
Вот примеры названий данного функционала у разных производителей, но все они значат одно и то же:
SIP ALG
SIP Helper
SIP Fixup
SIP Markup
SIP Translation
Например на роутерах Mikrotik, чтобы отключить данный функционал нужно зайти в IP → Firewall → Service Ports и убедиться, что сервис SIP выключен.
Либо отключить его используя CMD Mikrotik: /ip firewall service-port disable sip
Проблемы при подключении более 1 телефонного аппарата из одной и той же удаленной точки
Представьте, что Вы пытаетесь зарегистрировать два удалённых телефона на своей IP-АТС. Пусть их внутренние номера будут 100 и 101. Когда эти телефоны будут отправлять запрос регистрации, то Ваша IP-АТС получит его от удалённого роутера, за которым находятся эти телефоны и запрос этот будет от одного и того же IP адреса. Может быть эти телефоны и зарегистрируются на АТС, но когда на один из этих номеров будет поступать вызов, то удалённый маршрутизатор не сможет разобраться на какой из телефонов его отправлять 100 или 101.
Лучшим решением данной проблемы – будет организация виртуальной локальной сети (VPN) между удалёнными точками и IP-АТС. Тогда телефоны, находящиеся в удалённых офисах смогут регистрироваться на IP-АТС как если бы они находились в одной локальной сети.