Safari 14.0.3 Запрашивает разрешение на использование средств массовой информации (WebRTC) во второй раз после отказа в первом

#safari #webrtc #getusermedia

Вопрос:

я думаю, что у меня неожиданное поведение getUserMedia в Safari, и я хотел бы знать, не пропустил ли я что-то.

В Chrome/Firefox, если я не разрешу первое getUserMedia({audio: true, video: true}) приглашение, каждый следующий вызов к нему завершится ошибкой: NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. и это кажется прекрасным.

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

Я создал здесь простое хранилище воспроизведения, которое вы можете запускать в каждом браузере для сравнения (вы должны отказаться от первого запроса, чтобы воспроизвести ошибку). Странно, что один и тот же код работает каждый раз на jsfiddle только для safari и сохраняет то же поведение для другого браузера (я думаю, из-за iframe, в котором выполняется код)

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

Заказ вызова getUserMedia:

 // 1: press "Not allow"
getUserMedia({ video: true, audio: true });

// 2: will prompt again (that's the bug) and press "Allow"
getUserMedia({ video: true, audio: true });

// 3: will fail (that's the expected behaviour)
getUserMedia({ video: true, audio: true });

// 3bis: will fail too (that's the expected behaviour)
getUserMedia({ video: {deviceId: {exact: 'aValidDeviceId' }}, audio: {deviceId: {exact: 'aValidDeviceId' }} });
 

Я что-то пропустил или это действительно ошибка в safari ?

С уважением

Комментарии:

1. В чем здесь проблема? Почему ваш код заботится о том, когда Safari терпит неудачу "NotAllowedError" ?

Ответ №1:

В Сафари здесь нет ничего плохого. Браузер-это «агент пользователя« в глазах спецификаций, которые говорят:

Это намеренно расплывчато описывает детали пользовательского интерфейса разрешений и то, как UA определяет намерения пользователя. UAS должны иметь возможность исследовать множество пользовательских интерфейсов в рамках этой структуры.

В Интернете нет единой модели разрешений. Это хорошая вещь.

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

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

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

Поэтому правильный способ отреагировать на a "NotAllowedError" -предположить, что он исходил от пользователя. В тех случаях, когда это исходит от агента пользователя, предположим, что агент действует в интересах своего пользователя.

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

Разрешения — это сложно.

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

Браузер («агент пользователя») является единственной доверенной стороной, которая, как считается, действует в наилучших интересах своего пользователя, когда дело доходит до разрешений. Сайтам нельзя доверять управление ими.

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

Отказ от ответственности: Разрешения развиваются

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

Поэтому, возможно, бывают случаи, когда социальная инженерия вокруг какого-либо браузера оправдана (после того, как вы зарегистрировали в нем ошибки). Но в stackoverflow я думаю, что мы сначала должны дать «правильный» ответ и предварить все остальное в качестве обходных путей.

Ответ №2:

Это не совсем ошибка. Это ожидаемое поведение. Safari, в отличие от Chrome(ium) и Firefox, не настаивает на принятии или отклонении пользователями разрешения на доступ к мультимедиа.

Он спрашивает снова в следующий раз, когда пользователь говорит «да», а также когда она говорит «нет».

Было бы неплохо, если бы медиа-материалы Safari были предсказуемы для разработчиков, привыкших к другим браузерам, но это не так.

Комментарии:

1. Спасибо за ваш ответ 🙂 я тоже понял, что это не предсказуемо, но меня удивляет, что при отказе от первого запроса только второй вызов getUserMedia снова вызовет запрос, все остальные будут завершены с ошибкой NotAllowedError независимо от ответа, который вы дали

2. Однажды я попал в такую ситуацию, когда у меня не было времени. У меня не было времени, чтобы разобраться в этом. Я думаю , что переход в Настройки / Конфиденциальность / Safari и очистка разрешений камеры приведет к сбросу настроек. Но вы никак не можете разумно попросить пользователя веб-сайта сделать это.

3. Да, определенно не жизнеспособное решение (даже если проблема, о которой я упоминаю, появляется на странице первого посещения), мечтал бы, чтобы после отказа все последующие вызовы, такие как Chrome или Firefox, по крайней мере, были согласованными. Я добавил видео с воспроизведением, чтобы лучше понять ситуацию в исходном вопросе