OAuth User-Agent Flow z aplikacją pulpitu C#

Aktualnie próbuję używać przepływu User-Agent OAuth 2.0 z aplikacją C# klienta i mam pewne niejasności związane z przekierowaniem URI.OAuth User-Agent Flow z aplikacją pulpitu C#

Ponieważ pracuję z aplikacją klienta, nie mogę dostarczyć standardowego przekierowania do serwera WWW. Jednak według osób, z którymi próbuję się uwierzytelnić (Salesforce, w tym przypadku), User-Agent Flow jest właściwym rozwiązaniem dla aplikacji klienta.

Moje pytanie brzmi, co mogę zrobić, aby złapać token dostępu w tej sytuacji? Najwyraźniej mogę utworzyć "lokalny zasób dostępny dla klienta", ale nie jestem zaznajomiony z mechaniką stojącą za tym i nie mogę znaleźć żadnych zasobów na ten temat (częściowo dlatego, że nie wiem, czego szukać).

Wszelkie wskazówki dotyczące tego, gdzie powinienem zacząć szukać, byłyby bardzo mile widziane.

Edycja: Niektóre więcej kopania wykazała następujące pytanie stackoverflow:

How do I develop against OAuth locally?

robię kilka śledztwo z tym, co sugeruje, ale wszelkie inne sugestie byłyby świetne.

Edycja: Niektóre Wyszukiwanie ujawnił ten artykuł:

http://sarangasl.blogspot.com/2010/09/create-simple-web-service-in-visual.html

nadal czuje jakbym grzebie się w ciemności bez zrozumienia większy obraz, ale wierzę, że muszę skonfiguruj lokalną usługę sieciową za pomocą localhost i wskaż tam mój przekierowy URI. Następnie skorzystam z mojej usługi internetowej, aby rozwinąć odpowiedź z serwera OAuth i odpowiednio zareagować na moją aplikację. Więcej aktualizacji, które przyjdą.

Ooookay. Z tego, co udało mi się zebrać, muszę skonfigurować lokalną usługę sieciową, która będzie dostarczać jako callback dla OAuth. Muszę osobiście wysłuchać tej usługi internetowej i złapać wywołanie zwrotne, aby przekazać ją do mojej aplikacji. Jednak domyślna usługa sieciowa ASP.NET dostarczona przez VS2010 nie obsługuje parametrów URL, tylko wywołań API, więc najwyraźniej potrzebuję użyć zestawu startowego WCF Rest.

Jestem całkowicie obcy temu wszystkiemu, więc wszelkie wskazówki będą w tym momencie wybawieniem. Ogólnie rzecz biorąc, myślę, że skonfiguruję lokalną usługę WCF Rest, dostarczam lokalny URI do OAuth jako wywołania zwrotnego, a następnie przechwytuję adres URL wywołania zwrotnego za pomocą usługi Rest. Następnie analizuję adres URL i wyodrębniam token dostępu. W tym momencie moja aplikacja żąda tokenu dostępu lub moja usługa internetowa może "przekazać" token do mojej aplikacji? Tj. Gdzie powinno znajdować się miejsce kontroli?

Źródło

2012-05-31 sichinumi

Wymyśliłem sprytny sposób obejścia tego problemu. Zamiast skonfigurować usługę do nasłuchu przekierowania URL OAuth, umieściłem formant WebBrowser w moim formularzu Windows.

Wskazałem ten wbudowany WebBrowser na adres URL uwierzytelnienia i pozwoliłem użytkownikowi zalogować się i uwierzytelnić w Salesforce oraz udzielić pozwolenia mojej aplikacji.Następnie pozwolę Salesforce przekierować moją wbudowaną przeglądarkę do fałszywego URL-a przekierowania, który dostarczam. To przekierowanie nigdy nigdzie nie dociera, po prostu pojawia się jako 404.

Jednak monitorując WebBrowser.Url, mogę pobrać cały adres URL, do którego jest kierowana moja kontrolka wbudowanego WebBrowser, w tym dołączony token dostępu przez Salesforce. Zasadniczo po uwierzytelnieniu i przyznaniu uprawnień wbudowana przeglądarka jest przekierowywana do "http://www.dummyurl.com". Salesforce dołącza token dostępu, więc WebBrowser.Url kończy się szuka czegoś takiego:

http://www.dummyurl.com#access_token=ABCDEF&instance_url=ABCDEF

Stąd można po prostu analizować adres URL i przejść na mojej drodze. Nie jest wymagany serwer stron trzecich ani lokalna usługa internetowa. :)

Źródło

2012-06-01 19:40:49 sichinumi

To byłaby opcja. Ale bądź ostrożny: użytkownik może wykorzystać niektóre sztuczki w przeglądarce WebBrowser, takie jak przechodzenie do przodu i do tyłu w historii przeglądarki, odświeżanie strony, limity czasu, awaria sieci. Będziesz musiał obsłużyć wszystkie kody błędów HTTP + wszystkie paskudne sztuczki osadzone w przeglądarce. Powodzenia :) –

Plus rozważmy interfejs użytkownika Twojej aplikacji, który prawdopodobnie będzie inny od tego proponowanego przez Salesforce - i nie możesz zmienić swoich ustawień domyślnych, ponieważ nie masz nad nim kontroli. –

Ugh, masz rację. Będę musiał następnie przyjrzeć się bezpieczeństwu wbudowanych przeglądarek. Jeśli chodzi o interfejs użytkownika, moja aplikacja jest procesem działającym w tle, który generuje wyskakujące okienka na niektórych zdarzeniach, więc uwierzytelnianie jest wymagane tylko raz po uruchomieniu aplikacji (zwykle raz dziennie, rano). Dzięki za porady jednak zapomniałem o lukach w zabezpieczeniach, które mogłyby zostać otwarte dzięki osadzonej instancji IE. – sichinumi

Wywołanie typu autoryzacji, którego potrzebujesz Autonomiczny klient 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. Przeczytaj o adresie URL, który musisz tam przesłać.

grant_type=password&client_id=<your_client_id>&client_secret=<your_client_secret>&username=<your_username>&password=<your_password>

Źródło

2012-06-01 13:38:26

Niestety nie mogę wykorzystać tego przepływu. Jeśli adres IP próbujący uwierzytelnienia nie znajduje się na białej liście, hasło musi być dołączone z tokenem bezpieczeństwa użytkownika, co nie jest opcją dla mojej aplikacji. – sichinumi

Połóż to na swoim proxy, które zostanie dodane do białej listy. Dodatkowo link to 'POST'ed - więc parametry żądania będą szyfrowane przez HTTPS. Czy masz jakiś problem z tym podejściem? –

Hmm, nie myślałem o tym, żeby go przeprosić. Jednak rozwijam tę aplikację dla innych użytkowników w innych środowiskach biznesowych, a routing całego ruchu za pośrednictwem zewnętrznego serwera proxy nie jest opcją. Nie mam też kontroli nad białymi listami dla różnych organizacji moich użytkowników. Na koniec, twórcy API wyraźnie powiedzieli mi, że należy unikać przepływu OAuth User-Password. Nie mam z tym żadnych problemów osobiście, ale spójrz na moją drugą odpowiedź i daj mi znać, co o niej myślisz. :) – sichinumi

Możesz użyć biblioteki DotNetOpenAuth. Istnieje przykład użycia WPF, w którym wykorzystuje on formant WinForm o nazwie ClientAuthorizationView dostarczany przez bibliotekę DotNetOpenAuth.

Jest to kontrolka obsługująca przeglądarkę, która pozwala użytkownikowi autoryzować klienta bez opuszczania aplikacji.

Mam nadzieję, że ta pomoc.

Pozdrawiam

Źródło

2013-05-28 07:00:13 dave

OAuth User-Agent Flow z aplikacją pulpitu C#

Odpowiedz

Powiązane problemy