Niestandardowe uwierzytelnianie (model użytkownika) dla chmurowych punktów końcowych - Python

Question

Pracuję nad aplikacją na Androida z zapleczem GAE, sesjami itp. Chcę używać Google Cloud Endpoint i tworzyć interfejs API z niestandardowym modelem użytkownika uwierzytelniania. Nie chcę używać oauth google. Chcę zaimplementować prosty model uwierzytelniania poczty e-mail/użytkownika z tokenem opartym na sesji. Nie mam żadnego doświadczenia z GAE. Pracowałem w Pythonie i jego frameworkach (django, flakon, itp.).

Szukałem przykładowego projektu tego rodzaju w ubiegłym tygodniu (bez powodzenia).

Czy ktoś może podać mi przykładowy kod/zasób, jak zaimplementować taki punkt końcowy z zarządzaniem sesją i ochroną csrf wraz z ssl?

Ps: Jeśli uważasz, że punkty końcowe w chmurze nie są dobrym podejściem do mojej aplikacji (serwer zaplecza), to proszę, kieruj mnie do źródła, które może mi pomóc w tworzeniu własnego interfejsu API RESTful z kodowaniem JSON + ochrona crsf i zarządzanie sesją .

już widać następujące ale żaden z nich nie posiada szczegółowe rozwiązania:

• Custom Authentication for Google Cloud Endpoints (instead of OAuth2)
• Google App Engine: Endpoints authentication when custom auth or Open ID is used
• AppEngine Cloud Endpoints and custom Users service

Answer 1

Jesteś w na przejażdżkę. To nie jest prosty proces, ale udało mi się zrobić dokładnie to, czego szukasz - choć w nieco hackish sposób.

Po pierwsze, nie jest to projekt boilerplate na GAE (w Pythonie), która implementuje niestandardowe e-mail/pwd system logowania za pomocą dodatków webapp2 za: http://appengine.beecoss.com/

Wynika wytyczne dotyczące konfigurowania niestandardowego uwierzytelniania opisaną w tym blogu: http://blog.abahgat.com/2013/01/07/user-authentication-with-webapp2-on-google-app-engine/

Ten projekt ustawi opcje, aby użytkownik mógł rozpocząć sesję po zalogowaniu. Teraz, aby uzyskać dostęp do informacji o użytkownikach w tej sesji w punktach końcowych, należy postępować zgodnie z instrukcjami do tego first StackOverflow link you posted.

Klucz, po wykonaniu poprzednich kroków, polega na dopasowaniu klucza sesji w punktach końcowych do klucza sesji w pliku konfiguracyjnym kodu standardowego. Wtedy będziesz w stanie uzyskać, który użytkownik składający wniosek i po drodze z zaproszenia końcowego, jeżeli są one zatwierdzone:

self.get_user_from_cookie() 

    if not self.user: 
     raise endpoints.UnauthorizedException('Invalid token.') 

Jest niewiarygodnie śmieszne, że tak to działa uwierzytelniania niestandardowego, więc jeśli jesteś przyzwyczajony do Django i chciałbyś zaimplementować swoją aplikację w ten sposób, ZRÓB TO. Było "za późno, aby zawrócić" dla mnie i gardzę Google za dokumentowanie tylko schematów uwierzytelniania, które działają tylko dla posiadaczy kont Google.

OP, po prostu użyj Django na GAE i oszczędzaj sobie frustracji. Jestem przekonany, że istnieje wiele szybkiej integracji z aplikacjami mobilnymi, które może zapewnić społeczność Django.

Nikt nie chce zmuszać użytkowników swoich aplikacji do posiadania kont Google w celu zalogowania się, Google. Przestań.