(1) используйте форму и разместите информацию. Это может потребовать дополнительного кода на исходных страницах,но не должно требовать логических изменений на целевых страницах (просто запрос на изменение.Строка запроса к запросу.Форма). Хотя POST не так уж и невозможно испортить, он, безусловно, менее привлекателен, чем игра с параметрами QueryString.
(2)Используйте переменные сеанса для переноса информации со страницы на страницу. Это, вероятно, более существенное усилие по сравнению с (1), потому что вам нужно будет учитывать проверку переменных сеанса (например, теперь пользователю может быть трудно перемещаться с помощью кнопок Назад и вперед, если вы постоянно проверяете состояние). Вам также нужно будет иметь дело со случаем, когда сеансовые файлы cookie не включены (это решение не будет работать для этих людей).
(3)Используйте "закодированную" или несущественную информацию в строке запроса вместо реальных данных. Это потребует усилий по созданию схемы кодирования и декодирования на обоих концах всех представленных страниц. Конечно, пользователи все еще могут экспериментировать и перепроектировать вашу схему, однако у них будет меньше шансов быстро внести значимые изменения в существующую строку запроса.
(4)Использование фреймов. Я действительно не рекомендую этот подход, хотя он довольно распространен. Если вы пытаетесь скрыть информацию, а не затруднить ее изменение, пользователи все равно могут щелкнуть правой кнопкой мыши отдельные фреймы и выбрать пункт Свойства, чтобы получить всю информацию, переданную через строку запроса.
(5) Используйте Сервер.Передача для перемещения элемента управления на вторую страницу, которая по-прежнему будет иметь доступ к параметрам строки запроса, переданным на первую страницу (URL-адрес которой был виден только ненадолго).
Одна из проблем, связанных с отходом от строк запросов, заключается в том, что они затрудняют использование вашего сайта. Если вы полагаетесь на какой-либо метод, отличный от (3), пользователи не смогут добавить текущую страницу в закладки как есть... они могут только добавить страницу в закладки таким образом, который напоминает то, что произошло бы, если бы они просто ввели URL-адрес (который может даже не работать, в зависимости от того, как вы построили страницу). Так что это только одна вещь, которую нужно иметь в виду, когда решаете, насколько чувствительна ваша информация на самом деле, и как далеко вы готовы пойти в балансе удобства использования и безопасности.
Также проверьте эти страницы;
http://www.codeproject.com/aspnet/urlrewriter.asp[^]
http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx[^]
Хороший ответ! 5++
спасибо.
Мне нравится твой набор возможностей, мой 5!
Я предлагаю, чтобы этот ответ был принят ОП.
Я также хотел бы увидеть некоторую оценку каждого из них и предупреждение против сокрытия чего-либо в URL, сделанное Генри. Вот почему мне больше всего нравится его ответ.
--СА
Сокрытие любой части url-адреса очень подозрительно. Это то, что используется в фишинговых атаках.
Если вы посмотрите на url-адрес, отображаемый для вашего вопроса, он не использует идентификатор, он использует именованную страницу. Это гораздо лучший способ сделать это.
Генри, это лучший ответ на данный момент, мой 5.
Предложите его в качестве окончательного ответа, который будет принят ОП.
Я бы также объединил его с рекомендацией использовать POST вместо параметра URL - просто обратитесь к другим ответам.
--СА
0) вы можете создать строку GUID и поместить свое значение в известную позицию в строке.
1) я думаю, что вы действительно можете скрыть строку запроса (а не отображать ее в адресной строке) - google-ваш друг.
2) google "asp.net единый вход"
используйте для этого urlrewriting