Плюсы и минусы использования идентификатора БД в URL?

Question

Например: http://stackoverflow.com/questions/396164/exposing-database-ids-security-risk и http://stackoverflow.com/questions/396164/blah-blah загружают один и тот же вопрос.

(Полагаю, это таблица идентификаторов БД таблицы вопросов? Является ли это стандартом в ASP.NET?

Каковы плюсы и минусы использования схемы такого типа в вашем веб-приложении?

Answer 1

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

Загружать JSON во время выполнения, а не динамически через AJAX https://stackoverflow.com/questions/395858/doesnt-matter-what-I-type-here

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

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

Кроме того, здесь, в SO, вполне нормально использовать подобные ссылки на другие вопросы, поэтому, если они в какой-то момент захотят переиндексировать и, таким образом, изменить нумерацию (или перейти на guid), им все равно придется сохранить старую структуру и идентификаторы.

Теперь, это может когда-нибудь случиться или понадобиться? Вероятно, нет.

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

Answer 2

1. Идентификатор базы данных используется для поиска вопроса в базе данных. Это численно, что означает: быстро. Если вы пропустите это, вам придется искать заголовок, который намного медленнее.

2. Сам вопрос является частью URL, чтобы сделать его "дружественным для поисковых систем". Это будет более высокий рейтинг по г ** г и т. Д.

Answer 3

Pro:

• Супер легко получить информацию о странице. Возьмите удостоверение личности, позвоните в базу данных, альт. Ваша таблица будет (должна) быть проиндексирована, чтобы сделать этот поиск очень быстрым.
• Гарантированный уникальный URL.

Con:

• Идентификаторы в вашей системе отображаются публично. Не проблема в общедоступной системе, такой как SO. Однако надлежащие меры безопасности на стороне сервера могут сделать это не проблемой даже для чувствительных систем.
• Уродливые URL. Числа, состоящие из 6 и более цифр, просто трудно запомнить, и это затрудняет распознавание страниц, если это все, что их идентифицирует. Это также может иметь последствия для SEO, поскольку URL-адреса с более релевантной и хорошо структурированной информацией обычно ранжируются лучше. SO компенсирует это, предоставляя также название поста в URL. Несмотря на то, что я до сих пор не могу передать конкретное сообщение моему собеседнику за ланчем, мне все равно легче найти его в истории браузера.
• Медленный поиск. Выполнение текстового поиска в базе данных обычно медленнее.

Answer 4

Я не думаю, что это плохая практика, и довольно распространенная, делать это в ASP.NET и других средах. Как сказал @lassevk, если от этого зависит ваша безопасность, то вам нужно еще несколько проверок (может ли пользователь X получить запись Y), но это больше сводится к SEO-дружественности URL-адресов для публичных сайтов.

Например, URL-адреса SO являются довольно дружественными:

За и против использования идентификатора БД в URL?

Google оценивает информацию при НАЧАЛЕ URL выше, чем в конце, поэтому она будет выглядеть так:

https://stackoverflow.com/pros-and-cons-of-using-db-id-in-the-url/q/407120

должен получить более высокий рейтинг для "за и против использования db id в URL" . Это не единственный фактор, но он довольно важный - посмотрите на формат Amazon, они делают это по очень веской причине:

http://www.amazon.com/Maverick-Ricardo-Semler/dp/0712678867

http://server/book-name/dp/book-id

Wordpress делает это так:

http://server/yyyy/mm/dd/name-of-the-post

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

http://server/yyyy/mm/dd/foo

http://server/yyyy/mm/dd/foo2

slug (foo / foo2) не PK, но он поддерживается как уникальный по сравнению с таблицей сообщений.

Я думаю, что размещение идентификатора в URL не является проблемой, если ваш URL не является GUID! Слишком долго и сложно набрать. Если это int или какое-то короткое руководство (например, 6-8 символов), то это не должно быть проблемой.

Answer 5

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