ASP.NET MVC предложил маршрутизацию для URL с токеном сеанса - PullRequest
Новая
       28

ASP.NET MVC предложил маршрутизацию для URL с токеном сеанса

0 голосов
/ 22 ноября 2010

Я пытаюсь реализовать небольшой сайт ASP.NET MVC, который взаимодействует с другим сайтом. Короче говоря, сеансы управляются между основным сайтом и спутниковыми сайтами через токены в URL. Я могу указать формат URL, но не могу отменить требование, чтобы маркер сеанса был представлен как часть URL.

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

routes.MapRoute("Main", "{controller}/{action}/{id}/{token}");

Предоставляет URL-адреса, такие как http://mysite.com/Products/Detail/5/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f Pro: в основном соответствует существующему соглашению MVC для создания сайтов. Con: Добавляет усложнение к маршрутизации при поддержке значений по умолчанию для ID и Action. 

routes.MapRoute("Main", "{token}/{controller}/{action}/{id}/");

Предоставляет URL-адреса, такие как http://mysite.com/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f/Products/Detail/5 Pro: упрощает маршрутизацию - все еще может применять значения action / id по умолчанию согласно стандартному соглашению MVC Con: очень "не похожие на веб" URL. Требуется регулярное выражение для проверки того, что первая переменная является действительным GUID / токеном, прежде чем переходить к следующему маршруту в таблице.

Еще одна возможность приходит на ум, проходя такие сеансы, как: 

http://mysite.com/Home/Index?session=5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f

С этим связана проблема, связанная с тем, что у меня есть базовый класс, производный от Controller, через который проходят все другие защищенные страницы. Класс SecureController переопределяет Execute () и проверяет действительность токена, взятого из URL. Оба подхода (GET и маршрутизация), кажется, было бы достаточно просто получить токен в функции контроллера Execute (), но подход GET выглядит немного неуклюжим, в то время как подход маршрутизации кажется, что из-за отсутствия лучшего объяснения сломать элегантность маршрутизации MVC.

Кто-нибудь еще сталкивался с подобной проблемой и имел какие-либо конкретные успехи или трудности, которыми можно поделиться?

1 Ответ

2 голосов
/ 22 ноября 2010

Кажется, что бы вы ни делали, ваши URL-адреса будут довольно запутанными с этим токеном.

Мне приходилось обрабатывать такую ​​функцию единого входа также в приложении ASP.NET MVC, ноЯ выбрал немного другой и гораздо более простой подход: я создал GatewayController с действием SignOn, в котором в качестве параметров использовался токен сеанса и URL-адрес.

Тогда это действие SignOn просто проверило бысрок действия токена сеанса, а затем зарегистрировать пользователя на моем сайте, перенаправив на указанный URL-адрес.С этого момента токен сеанса больше не нужен, поскольку аутентификация с этого момента будет основываться на файлах cookie.

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

...