Google API: jak uwierzytelnić bez przekierowania?
Chcemy używać Google doc API do generowania dokumentów (na naszym własnym koncie biznesowym), gdy nasi użytkownicy wykonują pewne czynności na naszej stronie.
Problem polega na tym, że próbowaliśmy zaimplementować protokół OAuth 2.0, jak sugerowano w dokumentacji protokołu v3. 0. Metoda uwierzytelniania apiClient:: wykonuje przekierowanie. Jest to poważny problem, ponieważ nasi użytkownicy nie znają dostępu do własnego konta biznesowego.... i tak nie chcemy im dawać dostępu;)
(innymi słowy, nie tworzymy aplikacji, która pozwala naszym użytkownikom na edycję własnych danych, ale na interakcję z naszymi danymi, jak baza danych.)
Czytałem, że celem OAuth 2.0 było unikanie zarządzania poświadczeniami naszych użytkowników. Osobiście jestem w porządku z tą koncepcją, ale w naszym przypadku nie chcemy uwierzytelniać się na koncie google naszych użytkowników ...
Więc, jakie byłoby najlepsze podejście, aby uzyskać poprawne uwierzytelnianie bez żadnej interakcji ze strony Użytkownika Końcowego ?
3 answers
To, co opisujesz, nie jest tym, jak zaprojektowano OAuth z trzema nogami.
3-legged OAuth polega na uwierzytelnianiu delegowanym , w którym użytkownik (który zna swoje hasło) może udzielić ograniczonego i odwołalnego dostępu do zasobów aplikacji. Ta aplikacja nigdy nie widzi hasła użytkownika. Istnieje wiele pracy zaangażowanych w celu bezpiecznego umożliwienia aplikacji podszywania się pod użytkownika.
To, co prawdopodobnie chcesz, to użyć (2-legged) OAuth flow, gdzie poświadczenia consumer_id/consumer_secret są osadzone w aplikacji. W tym przypadku aplikacja nie podszywa się pod użytkownika końcowego i nie byłoby przekierowania przeglądarki.
Oto kilka dalszych informacji na temat korzystania z 2-legged OAuth w Google Apps: http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
A to jest dobry opis 3 - vs 2-legged OAuth: http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-09-19 20:57:16
Będziesz musiał skorzystać z konta usługi. Zasadniczo jesteś hard coding dostęp do tego konta do aplikacji serwera. Następnie używasz funkcji udostępniania, aby zapewnić dostęp do konta to dla żądanej treści. Na przykład możesz udostępnić profil Google Doc lub Analytics z kontem usługi.
Oto pełna przykładowa implementacja zakładania konta serwisu, logowania, a następnie korzystania z niego.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-01 16:16:15
Dlaczego nie uzyskać jednej autoryzacji OAuth dla konta firmowego i mieć wszystkich użytkowników z tego konta. Ponieważ brzmi to tak, jakbyś chciał, aby każdy miał dostęp do danych dla jednego konta, szczegóły można ukryć przed Użytkownikiem końcowym.
Token dostępu byłby współdzielony przez wszystkich użytkowników i wszyscy trafiliby do tego samego konta bez żadnej autoryzacji dla własnego konta każdego użytkownika.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-09-09 21:26:29