IMVHO ваш коллега находится на правильном пути, но не совсем.
Хорошее правило, которому нужно следовать, состоит в том, что вы никогда не должны выставлять действительные идентификаторы в строке запроса, поскольку это дает подсказку относительноструктура вашей базы данных, и это немного облегчает кому-либо проведение атаки типа SQL-инъекции (они могут нацеливаться на конкретные записи, потому что знают идентификатор).
Итак, ваш коллега пытается этого добитьсяХотя и очень круглым способом.Лично я бы так не поступил, потому что умный злоумышленник просто определится с тем, что вы делаете, а затем поймете, что такое магическое число.Он также на самом деле ничего не делает для предотвращения атаки SQL-инъекцией на определенные записи, так как сгенерированное число может в любом случае соответствовать существующему ключу.Если вы полагаетесь на эту методологию, чтобы избежать атак SQL, у вас есть более глубокие проблемы, которые необходимо решить.
Редактировать
Упоминание альтернативывероятно, это справедливо.Поскольку вы используете C # и извлекаете параметры из строки запроса, я предполагаю, что вы используете ASP.NET.В этом случае важные идентификаторы могут храниться в сеансе или кэше.Вы можете хранить несколько элементов в пользовательском объекте данных, который затем сохраняете в сеансе (это избавляет от необходимости отслеживать множество идентификаторов, вам просто нужно знать один).ASP.NET управляет сеансом веб-приложения для вас, он уникален для каждого пользователя, и вы можете использовать его для хранения материалов при переходе от страницы к странице.
Если вы отслеживаете сеанс вручную или используете базу данныхчтобы сохранить информацию, относящуюся к сеансу, вы все равно можете сериализовать вышеупомянутый объект данных в базу данных, используя сгенерированный GUID в качестве ключа, и добавить этот GUID к строке запроса (шансы на успех невероятно малы, если пользователь портится сGUID, чтобы попытаться принять чей-то сеанс, вы можете еще больше снизить этот шанс, объединяя два GUID в качестве ключа и т. Д.).