Где лучше всего размещать идентификаторы базы данных на стороне клиента?

ProgramBox

Где лучше всего размещать идентификаторы базы данных на стороне клиента?

Post author:admin
Запись опубликована:30 апреля, 2023
Post category:Вопросы по программированию

#javascript #jquery #html #client-side

#javascript #jquery #HTML #на стороне клиента

Вопрос:

Я обслуживаю страницу с помощью ASP.Net. У меня есть функциональность добавления / редактирования / удаления элементов управления, которые я динамически добавлял с помощью jQuery на странице, некоторые из которых имеют связанные записи в базе данных. Где лучше всего разместить идентификатор (первичный ключ) для них, атрибут, data-*, jQuery.data()? Должен ли я беспокоиться, если идентификатор виден на стороне клиента?

Ответ №1:

Рекомендуется шифровать идентификатор записи на стороне клиента, чтобы обеспечить безопасность вашей базы данных. Обычно скрытое поле делает свое дело.

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

Ответ №2:

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

например

 tbl_person
 person_id INT PRIMARY KEY
 person_uuid VARCHAR(64)
 name VARCHAR(128)

Но чтобы ответить на актуальный вопрос, я предлагаю вам использовать атрибут соответствующего элемента, proabbly id

 <tr><td id="1234-5678">Paul </td></tr>

(отредактируйте, чтобы получить правильное форматирование кода)

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

2. 1 Отправка данных обратно в соответствии с идентификатором, полученным из браузера, также сопряжена с риском для безопасности. С помощью небольшого количества firebug пользователь может получить доступ к данным других людей, если сервер не ограничивает это механизмом сеанса.

Ответ №3:

Наилучшей практикой является использование jQuery.data(), поскольку это соответствует стандарту HTML5 для такой информации.

Ответ №4:

Вы можете добавить свой собственный атрибут к элементу (например, my-attr="92" ), вы можете использовать скрытое поле ввода со значением, равным id ( <input type="hidden" value="92" /> ), или вы можете просто использовать id атрибут (например id="db-92" ).

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

1. Я постоянно создаю свои собственные атрибуты и думаю, что это отличный способ! За исключением, конечно, того, что он не будет проверять 🙂

2. Гораздо лучше следовать стандартам и использовать data атрибуты: ejohn.org/blog/html-5-data-attributes (с помощью jQuery. data API).

3. @Martijn: но как насчет браузеров, которые не поддерживают HTML5?

4. Это все равно будет работать, потому что эти браузеры игнорируют эти атрибуты, но по-прежнему разрешают доступ к этим атрибутам; атрибуты данных не требуют специальной поддержки в браузере.

Ответ №5:

Вы никогда не должны размещать это на своем клиенте. Поскольку вы неизбежно вернетесь к своему серверу, чтобы получить доступ к данным, самое большее, вам следует ввести какую-либо форму ключа (например, dsource = ‘db3’ в качестве атрибута или в скрытом поле ..), а затем выполнить какой-либо поиск в серверном процессе.

1. Почему не совсем так? Я не понимаю, почему так плохо помещать <класс элемента=»{object_id: 9}»></element> в HTML, это не совсем угроза безопасности, если вы проверяете право собственности на объект.

2. Я не вижу, где проверка владения установлена в качестве условия операции. Даже тогда такая информация должна храниться отдельно. Пользователю (в браузере) нет необходимости знать такую информацию. (даже если это скрыто в разметке, ИМХО, это все равно представляет угрозу безопасности)

3. @Homer, я вижу, что вы отредактировали вопрос с момента моего первоначального ответа. Мой ответ особенно верен, учитывая, что вы используете asp.net. если вы используете методы страницы, _callbacks или веб-службы на сервере, отправка идентификатора базы данных клиенту ничего не даст, он должен быть легко доступен на сервере. Если вы обнаружите, что вам нужно что-то отправить клиенту, то сделайте это каким-нибудь ключом, а не фактическим идентификатором.

4. Как бы это было доступно на сервере без Postback и ViewState ? Например, без идентификатора на стороне клиента, как сервер узнает, какую запись удалить на основе <a> щелчка?

5. хммм … в вашем оригинальном (и исправленном) сообщении вы спрашиваете, Where is the best place to put the database id? что я принял за идентификатор базы данных (db name), теперь это звучит так, как будто вы имеете в виду «идентификатор записи». Если это так, то я неправильно понял ваш смысл и согласился бы с тем, что для идентификатора записи (первичного ключа) наилучшей практикой является добавление пользовательского атрибута к вашему тегу привязки, например <a id="deleteButton" pkey="1" onclick="deleteItem();">click to delete</a>

Ответ №6:

Я всегда использую библиотеку метаданных jQuery, которая по сути является функциональностью $().data(), заключенной в class (или любом другом) атрибуте объекта.

Найдите плагин метаданных jQuery здесь: «Этот плагин способен извлекать метаданные из классов, случайных атрибутов, дочерних элементов и атрибутов данных HTML5-*».

Итак, вы можете делать подобные вещи:

 <tr><td>Dave Jones</td><td><input class="delete_person {person_id: 90}" type="button" value="Delete this guy" /></tr>

затем с помощью jQuery:

 $('.delete_person.').click(function() { 
    // delete person 
    $.post('/controller/delete_person', {person_id: $(this).metadata().person_id},  
    function() {
     // the person was deleted
    }
});

Надеюсь, это поможет!