Имеется приложение asp, состоящее из 2-х страниц логин и отчет. Отчет виден только авторизованным пользователям.
Авторизация работает следующим образом:
пользователь вводит логин пароль на страничек логин и жмет ок
в обработчике события приложение обращается в базу 
если логин и пароль верные в сессию записывается что пользователь авторизован
редирект на отчет
отчет проверяет пользователя в сессии если все ок грузим отчет

Вопрос:
Как можно передавать логин и пароль и запускать авторизацию из приложения win forms. Есть способ с передачей логина пароля через строку запроса, мне этот способ кажется не очень безопасным ибо строку эту можно скопировать, к примеру, из истории. Подскажите куда копать?

Какой метод авторизации вообще используется?

Подработаю читателем мыслей:
Forms authentification поди? Тогда вам надо всего лишь сделать POST (обычно) запрос с логином и паролем (точно также как делает браузер), получить в ответ с секретными куками и далее эти куки подсовывать в каждый запрос что вы исполняете.
В качестве клиента можно использовать HttpClient
Пример установки кукисов ему: http://stackoverflow.com/questions/1237373...prequestmessage

Хотя зачастую делают еще дополнительно authenticationService ..

Это сообщение отредактировал(а) jonie - 7.11.2013, 10:43

Forms authentification буду теперь использовать   . Из winforms приложения открывать отчет предполагается вот так:


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

Это сообщение отредактировал(а) no0b - 7.11.2013, 11:03

ну тогда запускаться будет браузер, стало быть запустить его можно только передав URL туда, где в GET параметрах прошить логин и пароль и правильно эту ситуацию на серверной стороне обработать:
1) если у вас cookie-state аутентификация, тогда сервер увидит что куков нет (предположим что браузер их не содержит), перебросит (http 302) вас при настройках по умолчанию asp.net на страничку авторизации, куда в GET параметре ReturnUrl будет начальный url который вы передали. Из него можно выцепить логин-пароль, обработать в обработчике загрузки страницы и произвести авторизацию и если она успешна вызвать FormsAuthentication.SetAuthCookie и вернув юзеру HTTP 302 с Url-ом, равным GET параметру ReturnUrl. Перейдя по которому браузер отошлёт аутентифкационную куку, система аутентификации сможет аутентифицировать по ней юзера и покажет отчет.

2) если у вас cookie-less аутентификция, тогда можно из WinForms приложения пройти авторизацию (методику я указал), получить идентификатор сессии, который передаётся через GET параметр и уже при запуске браузера в Url подмешивать этот самый идентификатор.

Если первым способом то в истории браузера может остаться get запрос с сохраненными логином и паролем?
Второй способ:
в winforms послать get запрос странички логин с параметрами логин пароль  с помощью HttpClient->
в обработчике page_load странички логин, проверить логин и пароль, сгенерить ид отослать его в куках пользователю и  сохранить, в какую то глобальную переменную (типо листа активных сессий)->
на стороне winforms приложения получить из куков ид и открыть (уже в браузере) логин с параметром ид сесии -> 
опять же в page_load логина, проверить ид сесии, если он в листе выданных, то все ок и редирект на отчет. Так?  

Это сообщение отредактировал(а) no0b - 8.11.2013, 14:02

обыкновенно все же POST используют, но это уже от крисовти рук реализующего..


не в куках, читайте про cookieless аутентификацию  - она из коробки поддерживается.

Сделал аутентификацию описанным мною способом с обычными куками. 
Прием и ответ на post запрос организовал через generic handler.
При пост запросе generic handler принимает логин пароль ищет юзера и создает ид если все ок, который отдает пользователю и записывает в статический лист залогиненных юзеров, юзеру.
После форма логина открывается с параметром этим (временным ид) по нему юзер заходит и стирается он, так что второй раз по нему не зайти. Большое спасибо за инфу!





Это сообщение отредактировал(а) no0b - 12.11.2013, 15:54

Ну я бы все-таки делал cookieless аутентикацию ... ибо вот это:
 оно как раз и делает (id сессии и её статус).

пример в аттаче

Присоединённый файл ( Кол-во скачиваний: 7 )
 WebApplication2.rar 6,69 Kb

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