Google App Engine: Удостоверяване на крайни точки, когато се използва персонализирано удостоверяване или Open ID

Наскоро започнах с Google App Engine. Възнамерявам да използвам Flask за обслужване на уеб страници и API на Endpoints, за предпочитане с Endpoints-Proto-Datastore за всичко останало.

От самото начало изглежда, че механизмите за удостоверяване извън Google на GAE имат нужда от малко работа. Ще бъда благодарен за всяко хвърляне на светлина върху проблемите, които открих досега:

Персонализирано удостоверяване

Ако можете да напишете доставчик на Open ID като част от приложението, използвайте нещо като Python-OpenID и също така внедрете потребител в същия работен процес, така че да изглежда като редовно влизане. По този начин той се интегрира добре в това, което предоставя GAE Users API. Предполагам, че ако това е направено правилно, users.get_current_user() ще работи добре.

Ако искате да пропуснете писането на свой собствен доставчик на OpenID и вместо това да напишете система за удостоверяване на имейл/парола, използвайки Flask-Login, интегрирана с NDB, това също трябва да е наред. Обаче една озадачаваща част от информацията в документацията на GAE казва, че мога да инстанцирам потребителски обект като така:

user = users.User("[email protected]")

Въпреки това (няма user.put() метод тук) users.get_current_user() все още връща Няма. И така, каква би била ползата от конструирането на потребителския обект?

Упълномощаване на крайни точки

При включване на user=required в декоратора на метода за API на Endpoint-Proto-Datastore, OAuth изглежда работи веднага - всичко, което трябва да направите, докато го тествате в APIs Explorer, е да включите превключвателя OAuth 2.0 и да изберете валиден обхват на Oauth 2.0. Значи ли това, че ако внедрим доставчик на OpenID, който се интегрира правилно с Users API, няма да е достатъчно да използваме OAuth магията на Endpoints API?

Тук също изглежда, че конструирането на потребителски обект няма да помогне да се удовлетвори изискването за удостоверяване.

Как ще работи персонализираното удостоверяване/друго внедряване на OpenID с удостоверяване/упълномощаване на Endpoint API?


person The Machinist    schedule 17.06.2013    source източник
comment
Много добър въпрос. Искам да направя повече или по-малко същото нещо: да внедря някакъв вид основно удостоверяване с потребителско име/токен. Опитах със servletFilter, но изглежда, че servletFilters не работят с /_ah/api-URL.   -  person icyerasor    schedule 25.06.2013


Отговори (1)


Исках да не използвам oAuth, а по-проста форма на удостоверяване с потребител/токен.

И така, това, което направих, е да създам персонализиран ServletFilter, който се свързва с /_ah/spi/* и прихваща информацията за влизане от HTTPServletRequest там, ако е Endpoint-API-Request.

Изглежда, че работи досега, но не съм много сигурен дали това е начинът. Но тъй като никъде не намерих примери за не-oAuth-Auth, това в момента е най-добрият ми шанс.

Ще се радвам да получа съвети за най-добри практики от @bossylobster или @Dan Holevoet.

person icyerasor    schedule 25.06.2013