Вопросы Теги

Допустимые символы в cookie

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

Рабочий код: 

var pressme = document.getElementById('pressme');
var button1=document.getElementById('myBtn');
var button2=document.getElementById('myBtn1');

var showme = document.getElementById('showme');

button1.addEventListener('click', display1);

function display1(){                              //displaying red background
    pressme.style.display = 'none';
    showme.style.display = 'block';
    button1.style.display=  'none';
    button2.style.display=  'block';
}


button2.addEventListener( 'mousedown', event => {
 timeout = setTimeout(() => {
   pressme.style.display = 'block';
   showme.style.display = 'none';
   button2.style.display=  'none';
   button1.style.display=  'block';
  }, 3000 );
});

button2.addEventListener( 'mouseup', event => {
    if ( timeout ) clearTimeout( timeout );
});
<!DOCTYPE html>
<html>
<head>
  <title>Realtime communication with WebRTC</title>
  <link rel="stylesheet" href="css/main.css" />
</head>
<body>


<table id="pressme" style="width:100%" bgcolor="red" height =500px>
        <button id="myBtn">Try it red</button>

    </table>


<table id="showme" style="width:100%;display:none;" bgcolor="green"height=500px>
        <button id="myBtn1" style=display:none; >Try it green </button>

</table>

</body>
</html>

290
задан Moe Sisko 17 April 2013 в 19:29
поделиться

4 ответа

этот быстрый:

Вы можете подумать, что так и должно быть, но на самом деле это вовсе не так!

Какие допустимые символы в названии и значении куки-файла?

Согласно древней Netscape cookie_spec вся строка NAME=VALUE представляет собой:

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

Так что - должна работать, и в моих браузерах это, кажется, нормально; где у вас с этим проблемы?

Подразумевается, что:

  • = правомерно включать, но потенциально двусмысленно. Браузеры всегда делят имя и значение на первый символ = в строке, поэтому на практике можно поместить символ = в VALUE, но не в NAME.

О чем не упоминается, так как Netscape ужасно умел писать спецификации, но, похоже, последовательно поддерживается браузерами:

  • либо ИМЯ, либо ЦЕНА могут быть пустыми строками

  • , если в строке вообще нет символа =, браузеры рассматривают его как куки с именем пустой строки, т.е. Set-Cookie: foo - это то же самое, что и Set-Cookie: =foo.

  • , когда браузеры выводят куки с пустым именем, они опускают знак равенства. Таким образом, Set-Cookie: =бар получает значение Cookie: bar.

  • запятые и пробелы в именах и значениях, похоже, действительно работают, хотя пробелы вокруг знака равенства обрезаются

  • управляющие символы (\x00 до \x1F плюс \x7F) не допускаются

То, о чем не упоминается и о чем браузеры совершенно непоследовательны, это не-ASCII (Юникод) символы:

  • в Opera и Google Chrome они закодированы в заголовки Cookie с UTF-8;
  • в IE используется кодовая страница машины по умолчанию (локальная и никогда не UTF-8);
  • Firefox (и другие браузеры на базе Mozilla) используют младший байт каждой точки кода UTF-16 по отдельности (так что ISO-8859-1 в порядке, но все остальное искажено);
  • Safari просто отказывается посылать любые Cookie, содержащие не-ASCII-символы.

поэтому на практике вы вообще не можете использовать в cookie-файлах не-ASCII-символы. Если вы хотите использовать Unicode, управляющие коды или другие произвольные последовательности байтов, cookie_spec требует, чтобы вы использовали специальную схему кодирования по вашему собственному выбору и предложить URL-адреса кодирования (как производится JavaScript cododeURIComponent) в качестве разумного выбора.

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

  • RFC 2109 была попытка кодификации и исправить оригинальные Netscape печенья_spec. В этом стандарте запрещены многие другие специальные символы, так как он использует RFC 2616 маркеры (a - там разрешено -), и только значение может быть указано в строке кавычек с другими символами. Ни один браузер никогда не реализовывал ограничения, специальную обработку цитируемых строк и экранирование, или новые возможности в этой спецификации

  • RFC 2965 были еще одним шагом вперед, приведя в порядок 2109 и добавив дополнительные возможности по схеме "куки-версии 2". Никто никогда не реализовывал ничего из этого. Эта спецификация имеет те же ограничения по символике и кавычкам, что и предыдущая версия, и это просто куча чепухи.

  • RFC 6265 - это HTML5-эра попытки прояснить исторический беспорядок. Он все еще не совсем соответствует реальности, но гораздо лучше, чем предыдущие попытки - это, по крайней мере, правильное подмножество того, что поддерживают браузеры, не вводя синтаксиса, который должен работать, но не работает (как в предыдущей цитируемой строке).

В 6265 имя куки все еще указано в виде RFC 2616 токена, что означает, что вы можете выбрать из алфавитов плюс:

!#$%&'*+-.^_`|~

В значении куки формально запрещаются (отфильтрованные браузерами) управляющие символы и (непоследовательно-внеиспользованные) не-ASCII символы. Он сохраняет запрет cookie_spec на пробел, запятую и точку с запятой, плюс для совместимости с любыми плохими идиотами, которые на самом деле реализовали более ранние RFC, он также запрещает обратный слеш и кавычки, кроме кавычек, обертывающих все значение целиком (но в этом случае кавычки все равно считаются частью значения, а не схемой кодирования). Итак, остались алфавиты плюс:

!#$%&'()*+-./:<=>?@[]^_`{|}~

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

.
372
ответ дан 23 November 2019 в 01:43
поделиться

Еще одно соображение. Недавно я реализовал схему, в которой некоторые конфиденциальные данные, публикуемые в сценарии PHP, должны были преобразовываться и возвращаться в виде зашифрованного файла cookie, в котором использовались все значения base64, которые я считал гарантированно «безопасными». Поэтому я должным образом зашифровал элементы данных с помощью RC4, запустив вывод через base64_encode и благополучно вернул cookie на сайт. Тестирование шло хорошо, пока строка в кодировке base64 не содержала символ «+». Строка была записана в cookie страницы без проблем. С помощью диагностики браузера я также мог убедитесь, что файлы cookie были записаны без изменений. Затем, когда на следующей странице был вызван мой PHP и получен файл cookie через массив $ _COOKIE, я заикался, обнаружив, что в строке теперь отсутствует знак «+». Каждое вхождение этого символа заменялось на Пространство ASCII.

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

После того, как вы сделали любое шифрование, которое хотите сделать с частью данных, а затем использовали base64_encode, чтобы сделать его «безопасным для cookie», запустите вывод через эту строку ... 

// from browser to PHP. substitute troublesome chars with 
// other cookie safe chars, or vis-versa.  

function fix64($inp) {
    $out =$inp;
    for($i = 0; $i < strlen($inp); $i++) {
        $c = $inp[$i];
        switch ($c) {
            case '+':  $c = '*'; break; // definitly won't transfer!
            case '*':  $c = '+'; break;

            case '=':  $c = ':'; break; // = symbol seems like a bad idea
            case ':':  $c = '='; break;

            default: continue;
            }
        $out[$i] = $c;
        }
    return $out;
    }

Здесь я просто подставляю "+" (и я тоже решил "=") другими символами "cookie", прежде чем возвращать закодированное значение на страницу , для использования в качестве куки. Обратите внимание, что длина обрабатываемой строки не изменяется. Когда тот же (или другая страница на сайте) снова запустит мой PHP-скрипт, я смогу восстановить этот cookie без пропущенных символов. Мне просто нужно помнить, чтобы передать cookie обратно через тот же вызов fix64 (), который я создал, и оттуда я могу декодировать его с помощью обычной base64_decode (), за которой следует любая другая расшифровка в вашей схеме.

Могут быть некоторые настройки, которые я могу сделать в PHP, которые позволяют передавать строки base64, используемые в cookie, обратно в PHP без повреждения. В то же время это работает. «+» Может быть «допустимым» значением cookie, но если у вас есть желание передать такую ​​строку обратно в PHP (в моем случае через массив $ _COOKIE), я предлагаю повторную обработку для удаления оскорблять персонажей и восстанавливать их после восстановления. На выбор предлагается множество других «безопасных» символов.

0
ответ дан 23 November 2019 в 01:43
поделиться

Существует 2 версии спецификаций куки-файлов
. 1. Куки-файлы версии 0, также известные как Netscape,
. 2. Версия 1, также известная как RFC 2965 cookies
. В версии 0 часть имени и значения куки-файлов представляют собой последовательности символов, исключая точку с запятой, знак равенства и пробел, если не используется с двойными кавычками
. версия 1 намного сложнее, вы можете проверить ее здесь
В этой версии спецификации для наименования части значения почти одинаковы, за исключением того, что имя не может начинаться со знака $

.
1
ответ дан 23 November 2019 в 01:43
поделиться

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

.
17
ответ дан 23 November 2019 в 01:43
поделиться
Другие вопросы по тегам:

Похожие вопросы: