Обеспечение Запросов Ajax через GUID

Question

Обеспечение Запросов Ajax через GUID

Ожидаемая строка вывода, которую вы пытаетесь утвердить, должна быть

0 \ n1 \ n0 \ n

, поскольку существует println.

Метод исправленных юнит-тестов должен быть таким, как показано ниже.
    @Test
    public void test() {
        CountNumP2 cn = new CountNumP2();
        cn.countUpDown(0, 1);
        String output =  "0\n1\n0\n";
        Assert.assertEquals(output , outContent.toString());
    }

6

server-side guid security algorithm ajax

задан Aaron 17 March 2009 в 02:51

3 ответа

Это действительно зависит от того, что Вы пытаетесь выполнить безопасностью. Если Вы имеете в виду, предотвращают несанкционированное использование Конечных точек HTTP существует очень мало, можно делать с этим, так как у пользователя будет полный доступ к HTML, и JavaScript раньше выполнял вызовы.

Если бы Вы означаете препятствовать тому, чтобы кто-то осуществил сниффинг данных в запросах Ajax затем, я просто использовал бы SSL.

GUID, используемый в способе, которым Вы предлагаете, действительно просто переосмысливает идентификационный cookie сессии.

1

ответ дан 17 December 2019 в 00:14

"Обеспечение" является своего рода неопределенным термином. Что точно Вы пытаетесь выполнить? Используя GUID превосходный способ предотвратить дублирующиеся представления того же запроса, но это - все.

Если информация, передаваемая между клиентом и сервером, является действительно уязвимой, необходимо сделать это по HTTPS. Это - действительно единственный ответ до обеспечения фактической коммуникации, затронут.

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

1

ответ дан 17 December 2019 в 00:14

Другие вопросы по тегам:

server-side guid security algorithm ajax

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

score 5 · Accepted Answer

При выполнении этого для доверия коду, который Вы отправили в клиентский браузер, то измените направление. Вы действительно не хотите доверять вводу данных пользователем, который включает вызовы от js, который Вы отправили в браузер. Логика на сервере должна быть сделана так, чтобы ничто неправильно не могло быть сделано через там. Тем не менее asp.net использует поле значения со знаком, Вы могли бы хотеть пойти тем путем, если абсолютно необходимо.

Расширение немного: доказательства трамбовки Asp.net состояние отображения, которое отправляется как HTML скрытое поле (в зависимости от конфигурации). Я уверен, что существуют лучшие ссылки как ссылка, но по крайней мере она упоминается на этом: http://msdn.microsoft.com/en-us/library/ms998288.aspx

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

SHA1–SHA1 используется для вмешательства доказательства ViewState и, если настроено, билет аутентификации форм. Когда SHA1 выбран для атрибута проверки, используемый алгоритм является HMACSHA1.

Ссылка для класса .NET для того алгоритма http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx.

Обновление 2: Для проверки трамбовки Вы хотите подписаться, данные (не шифруют его). Обратите внимание, что при использовании криптографии в целом, необходимо действительно избегать использования пользовательской реализации или алгоритма. Относительно шагов я придерживался бы:

Присвойте маркер переменной JavaScript (сгенерированная серверная сторона). Вы включаете информацию для идентификации запроса и точного date&time, где это было выпущено. Подпись проверит серверное приложение, выпустил данные.
Определите дважды отправляет при необходимости.

Тем не менее причина, asp.net проверяет состояние отображения по умолчанию, то, потому что devs полагаются на информацию, прибывающую там как обрабатываемый только приложением, когда они не были должны. То же, вероятно, запрашивает Ваш сценарий, не полагайтесь на этот механизм. Если Вы хотите оценить, может ли кто-то сделать что-то, используют authentication+authorization. Если Вы хотите знать, что вызов ajax отправляет только допустимые опции, проверьте их. Не выставляйте API на уровне гранулярности, чем тот, где можно соответственно авторизовать действия. Этот механизм является просто дополнительной мерой, в случае, если что-то скользило, не реальная защита.

Ps с HMACSHA1 выше, Вы инстанцировали бы его с фиксированным ключом