Поток пользовательского агента OAuth с настольным приложением C#
В настоящее время я пытаюсь использовать поток пользовательского агента OAuth 2.0 с клиентским приложением C#, и я сталкиваюсь с некоторой путаницей, связанной с URI перенаправления.
Поскольку я работаю с клиентским приложением, я не могу предоставить стандартный URL-адрес перенаправления на веб-сервер. Однако, по мнению людей, с которыми я пытаюсь пройти аутентификацию (Salesforce, в данном случае), поток User-Agent является правильным для использования в клиентском приложении.
Мой вопрос в том, что может Я делаю, чтобы поймать маркер доступа в этой ситуации? Очевидно, я могу создать "локальный ресурс, доступный клиенту", но я не знаком с механикой этого, и я не могу найти никаких ресурсов по этой теме (отчасти потому, что я не знаю, что искать).
Любые указания относительно того, где я должен начать искать, будут очень оценены.
Edit: еще несколько раскопок выявили следующий вопрос stackoverflow:
Как я развиваюсь против OAuth локально?
Я делаю еще несколько исследований с тем, что они предложили, но любые другие предложения были бы также замечательны.
Edit: еще несколько поисков показали эту статью:
Http://sarangasl.blogspot.com/2010/09/create-simple-web-service-in-visual.html
По-прежнему кажется, что я блуждаю в темноте, не понимая общей картины, но я считаю, что мне нужно настроить локальный веб-сервис с помощью localhost и указать мой редирект Ури там. Затем я использую свой веб-сервис, чтобы развернуть ответ от сервера OAuth и заставить мое приложение ответить соответствующим образом. Еще больше обновлений, чтобы прибыть.
Оооокай. Итак, из того, что я смог собрать, мне нужно настроить локальный веб-сервис для предоставления в качестве обратного вызова для OAuth. Мне нужно самому прослушать указанный веб-сервис и поймать обратный вызов, чтобы передать его в мое приложение. Однако по умолчанию ASP.NET веб-служба, предоставляемая VS2010, не поддерживает параметры URL, только вызовы API, поэтому я видимо, нужно использовать стартовый комплект WCF Rest вместо этого.
Я абсолютно чужд всему этому, поэтому любые советы были бы находкой в этом месте. В общем, я думаю, что я настраиваю локальную службу WCF Rest, предоставляю этот локальный URI OAuth в качестве обратного вызова, а затем перехватываю URL обратного вызова с помощью службы Rest. Затем я анализирую URL-адрес и извлекаю маркер доступа. На этом этапе мое приложение запрашивает маркер доступа или моя веб-служба может "дать" маркер моему приложению? То есть, где должен быть локус контроля быть?
3 ответа:
Придумал умный способ обойти это. Вместо того чтобы настроить службу для прослушивания URL-адреса перенаправления OAuth, я встроил элемент управления WebBrowser в свою форму Windows.
Я указал этому встроенному веб-браузеру на URL-адрес проверки подлинности и позволил пользователю войти в систему и пройти проверку подлинности с помощью Salesforce, а также предоставить разрешения для моего приложения. Затем я разрешаю Salesforce перенаправить встроенный браузер на фиктивный URL-адрес перенаправления, который я предоставляю. Этот редирект никогда никуда не уходит, он просто появляется как 404.
Однако, путем мониторинга WebBrowser.Url, я могу выбрать весь URL, на который направлен мой встроенный элемент управления WebBrowser, включая маркер доступа, добавляемый Salesforce. В основном, после того, как пользователь аутентифицируется и предоставляет разрешения, встроенный браузер перенаправляется на "http://www.dummyurl.com." Salesforce добавляет маркер доступа, поэтому WebBrowser.Url в конечном итоге выглядит примерно так это:
Http://www.dummyurl.com#access_token=ABCDEF&instance_url=ABCDEF
Отсюда я могу просто разобрать URL-адрес и продолжить свой путь. Нет необходимости в стороннем веб-сервере или локальной веб-службе. :)
Вызов типа авторизации вам нужен Authonomous Client http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com#Obtaining_a_Token_in_an_Autonomous_Client_.28Username-Password_Flow.29. прочитайте об URL, который вы должны отправить туда.
grant_type=password&client_id=<your_client_id>&client_secret=<your_client_secret>&username=<your_username>&password=<your_password>
Вы можете использовать библиотеку DotNetOpenAuth. Есть пример использования WPF, где он использует элемент управления winforms под названием ClientAuthorizationView, предоставляемый библиотекой DotNetOpenAuth.
Это элемент управления, который содержит браузер, позволяющий пользователю авторизовать клиента, не выходя из приложения.
Надеюсь, это поможет.
С уважением