Google Chrome / macOS: поле пароля не будет принимать символы не ASCII - PullRequest
0 голосов
/ 01 мая 2018

Обновление

Очевидно, это нерешенная проблема с версией Google Chrome для OS X. Впервые об этом было сообщено более семи лет назад. Если вам посчастливилось ввести пароль, содержащий символы, не входящие в ASCII, то вам подойдут следующие варианты:

  • Введите пароль где-нибудь еще и перенесите его в поле пароля через буфер обмена.
  • Используйте инструменты разработчика, чтобы изменить тип ввода с password на text.
  • Использовать другой браузер

Существуют ли какие-либо правила относительно символов, которые можно вводить в поле пароля? Я экспериментировал с Chrome на Mac, и похоже, что я могу вводить «специальные» символы только в том случае, если они могут быть созданы одним нажатием клавиши (не включая клавиши-модификаторы, такие как Alt и Shift ).

Например, я могу ввести символ авторского права (©) одним нажатием клавиши ( Alt G ), но буква «o» с умлаутом (ö) требует двух ( Alt U , затем O ). В последнем случае умлаут не появится в пароле. В Windows кажется, что эти символы получаются путем ввода магических чисел при нажатии клавиши Alt , поэтому в этом поведении, вероятно, существуют межплатформенные различия. Также могут быть различия между браузерами.

Причина, по которой я спрашиваю, заключается в том, что я хочу реализовать форму регистрации с полем ввода пароля, которое можно переключить с type="password" на type="text". Это позволяет пользователю проверять содержимое поля (при условии, что это безопасно) и позволяет мне использовать генератор случайных паролей, чтобы предварительно заполнить это поле чем-то, что пользователь затем может скопировать в поле подтверждения. Но тем самым я меняю набор символов, которые принимает это поле. Это явно нежелательно; например, если я выберу Röntgen в качестве пароля, я никогда не смогу войти в систему (если форма входа также не переключается).

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

Чтобы проиллюстрировать проблему, вот форма с двумя полями пароля. Одно поле можно переключить на обычный текстовый ввод. Нажмите кнопку, чтобы открыть содержимое двух полей.

function reveal() {
  if ($('#p1').attr('type') == 'password') {
    $('#p1').attr('type', 'text');
    $('#r').html('(Hide)');
  }
  else {
    $('#p1').attr('type', 'password');
    $('#r').html('(Reveal)');
  }
}

function show_passwords() {
  $('#out1').html($('#p1').val());
  $('#out2').html($('#p2').val());
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<div>
  <form onsubmit="return false;">
    <p><label>Password:<br><input type="password" id="p1" name="p1" size="20"></label>
    <small><a id="r" href="#" onclick="reveal()">(Reveal)</a></small></p>
    <p><label>Confirm password:<br><input type="password" id="p2" name="p2" size="20"></label></p>
    <p><button onclick="show_passwords(); return false">Show password field contents</button></p>
  </form>
</div>
<table style="min-width:20em; border: 1px solid #bbb">
  <tr><td style="width:8em">Password:</td><td id="out1"></td></tr>
  <tr><td>Password confirm:</td><td id="out2"></td></tr>
</table>

1 Ответ

0 голосов
/ 02 мая 2018

Первоначальный автор отчета о хром-треке здесь. Мне сказали открыть ту же проблему в bugtraq веб-набора (тогда Chrome запускался на веб-наборе), и разработчик веб-набора сказал мне, что Cocoa (платформа OSX UI) не допускает символы не-ASCII в полях пароля ( и я уже обнаружил эту проблему, мой пароль OSX не так сложен, как пароли моих онлайн-сервисов) и что Webkit старается подражать нативному поведению. Так что проблема не в вашем браузере, а в самой OSX.

Если честно, когда Chrome переключился на Blink, в багтреке появилось новое сообщение:

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

В нынешнем виде Blink терпит неудачу обоими способами: мертвые ключи не ведут себя так, как в текстовых полях, и они также не следует за поведением NSSecureTextField (то есть ведет себя, хотя ключ не является мертвым ключом).

WebKit 601.2.7 в Safari 9.0.1 ведет себя как ожидалось. Должен ли Blink следовать за поведением платформы, или поддержка мертвых ключей в полях пароля предпочтительнее?

Но время прошло, и пока ничего не изменилось ...

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...