Congratulations, you just did a lot of stuff. Let's do
a recap. You've wrote your first lines of code and
deployed it to App Engine. You got Conference Central up
and running. And you've tried out the API Explorer. Don't underestimate
the API Explorer. It's a great tool to use to
try out the APIs. And it's not limited to your
own APIs, you can use it for any Google API.
So, all good stuff. But let's now talk about user authentication.
Many applications require that a user is registered and
signed in before using the application. We will also require
this for Conference Central, so let's look at how
we do that. It used to be the case that
almost every application had to create their own user
management system. That would mean that you would have to
write all the code from scratch in order for
your users to use your applications. Well, good for us.
That is not needed anymore. With App Engine, you
can use third party authentication with Cloud Endpoints, such
as Google Plus sign-in. But also other ones can
be used. In Conference Central, we will require a Google
account for sign-in. So, how do we know that
the user is signed into their Google account when they
use Conference Central? That is actually taking care of
by Cloud Endpoints. A Cloud Endpoint's API method can optionally
take a user object as its first argument and
if the user object is not null then the
user is signed in, but if it's null then
we throw in exception which decline should receive and
redirect for sign in. Could it be more easy?
Hm, you might say now. But what about security
and privacy? Well, that is all taken care of
by Google Sign in or a third party authentication provider.
So this mechanism is the best of two worlds combined. A simple way
to add user authentication to your app, combined with the strong security and
privacy standards of Google, all right, that's enough talking, time for you do
some coding again by adding user
authentication to your Conference Central. Good luck.
تهانينا، قمت بعمل كثير من الأشياء للتو. دعنا نقدم
ملخصًا. قمت بكتابة السطور الأولى للتعليمة البرمجية
ونشرتها في App Engine. وقمت بتنشيط Conference Central
وجارٍ تشغيله. وقمت بتجربة API Explorer. لا تستهن بمستكشف
API Explorer. فهي أداة مفيدة للتعود على
تجربة واجهات API. وهي غير محدودة لواجهات API
.الخاصة بك، بل يمكنك استخدامها لأي واجهة من Google API
.فهي مفيدة في العديد من الأشياء. لكن دعونا الآن نتحدث عن مصادقة المستخدم
تتطلب كثير من التطبيقات تسجيل المستخدم
وتسجيل الدخول قبل استخدام التطبيق. سنحتاج إلى هذا أيضًا
من أجل Conference Central، لذلك دعنا نتعرف على كيفية
القيام بذلك. فيما سبق كان
يجب تقريبًا على كل تطبيق إنشاء نظام
إدارة المستخدم الخاص به. هذا قد يعني أنه يجب عليك كتابة
كل التعليمات البرمجية من البداية بالترتيب
لمستخدميك لاستخدام تطبيقاتك. حسنًا، الخبر السار
أننا لم نعد بحاجة لذلك بعد الآن. باستخدام App Engine، يمكنك
استخدام مصادقة جهة أخرى بـ Cloud Endpoints، مثل
التسجيل في Google Plus. لكن يمكن استخدام مصادقات أخرى
أيضًا. في Conference Central، سنحتاج إلى إدخال حساب Google
لتسجيل الدخول. لذلك كيف يمكننا معرفة
ما إذا كان المستخدمون قد قاموا بتسجيل الدخول إلى حساب Google عند
استخدام Conference Central؟ يمكننا معرفة ذلك
عن طريق Cloud Endpoints. يمكن لأسلوب API الخاص بـ Cloud Endpoints
استخدام كائن المستخدم اختياريًا كالوسيطة الأولى له
وإذا لم يكن كائن المستخدم فارغًا، يتم تسجيل دخول
المستخدم، لكن إذا كان فارغًا
يصادفنا استثناء في تحديد أي رفض يجب تلقيه
وإعادة توجيهه لتسجيل الدخول. هل يمكن أن يكون الأمر أكثر سهولة؟
قد تعتقد ذلك الآن. لكن ماذا عن الأمان
والخصوصية؟ حسنًا، يتم الاهتمام بهذا كله
.عن طريق تسجيل الدخول إلى Google أو مزود مصادقة جهة أخرى
لذلك، فإن هذه الآلية هي نتاج الجمع بين أفضل آليتين في العالم. وهما الطريقة السهلة
لإضافة مصادقة المستخدم إلى تطبيقك مع الأمان القوي
ومعايير الخصوصية في Google. حسنًا، يكفي هذا الحديث، حان الوقت لتقوم
بإجراء بعض التعليمات البرمجية مرة أخرى عن طريق إضافة مصادقة
.المستخدم إلى Conference Central الخاص بك. حظًا موفقًا
Felicitaciones, hizo muchas cosas.
Recapitulemos.
Escribió sus primeras líneas de código
y las envió al motor de aplicación.
Organizó la Central de Conferencia
y la puso a funcionar.
También probó el explorador API.
No subestime el explorador API.
Es una gran herramienta
para probar los APIs
y no se limita solo a sus APIs,
lo puede usar
para cualquier API de Google.
Hablemos sobre autenticaciones de usuario.
Muchas aplicaciones requieren
que el usuario se registre y entre
registrado antes de usarlas.
Necesitaremos hacer esto también
en la Central de Conferencia.
Veamos cómo se hace.
Solía pasar que casi cada aplicación
tenía que crear su propio sistema
de manejo de usuario.
Eso significaba que tendría que escribir
el código desde el inicio
para que los usuarios
usaran sus aplicaciones.
Afortunadamente, eso ya no es necesario.
Con el motor de aplicación,
puede usar una autenticación
de un tercero con Cloud Endpoints
como los registros Plus de Google.
También puede usar otras.
En la Central de Conferencia,
se necesita una cuenta de Google.
¿Cómo sabemos que los usuarios
están en sus cuentas de Google
cuando usan la Central de Conferencia?
De eso se encarga Cloud Endpoints.
Un método API de Cloud Endpoint puede
tomar un objeto de usuario
como su primer argumento.
Si el objeto de usuario no está nulo,
se admite el usuario. Si es nulo, entonces
arrojamos una excepción,
cuyo rechazo debe ser recibido
y redirigido para la admisión.
¿Podría esto ser más fácil?
Quizá ahora se pregunte
sobre la seguridad y privacidad.
De eso se encarga
la entrada a Google o un tercer
proveedor de autenticaciones.
Este mecanismo es la mejor
combinación de dos mundos,
una manera simple de agregarle
autenticación a su aplicación junto
con los fuertes estándares
de seguridad y privacidad de Google.
Bien, es hora de que haga
un código nuevo
y agregue una autenticación de usuario
a su Central de Conferencia.
Buena suerte.
お疲れさまです
ここまでの学習内容をまとめてみましょう
コードの1行目を書きApp Engineに展開しました
Conference Centralをアップして実行し
APIs Explorerも使ってみました
APIs Explorerを侮らないでください
APIを試すのに最適なツールです
個人のAPIでも制限はありませんし
すべてのGoogle APIも使えるのです
ではユーザ認証についてお話ししましょう
多くのアプリは使用前に
ユーザ登録とサインインを求めます
Conference Centralでも同じです
詳しく見ていきましょう
以前はすべてのアプリケーションが
独自のユーザ管理システムを必要としていました
ユーザがアプリを使えるようにするためには
1からコードを書かなければならなかったのです
ありがたいことに今は必要ありません
App EngineではCloud Endpointsの
サードパーティ認証を使っています
Google+のサインインなどですが
他のものも使われます
Conference Centralでは
Googleでのサインインが必要です
ユーザがGoogleアカウントでサインインしたことが
どうやったら分かるのでしょう?
実はCloud Endpointsが管理しているのです
Cloud EndpointsのAPIメソッドは
ユーザオブジェクトを第1引数と見なします
ユーザオブジェクトが無効でなければ
サインインしている状態です
無効の場合は例外が発生し
アクセスを拒否して再度サインインを要求します
非常にシンプルですよね
ではセキュリティとプライバシーは
どうでしょうか?
すべてGoogleへのサインインや
サードパーティ認証で管理されています
この2つを組み合わせることにより
最大の効果が得られます
Googleのセキュリティとプライバシー基準を持つ
ユーザ認証機能を簡単にアプリに加えられるのです
さて説明はこのくらいにして
実際にコードを書いて
アプリにユーザ認証を加えてみましょう
Parabéns! Você acabou de realizar várias coisas. Vamos
recapitular. Você escreveu as primeiras linhas de código e
o implantou no App Engine. Você colocou o Conference Central
para funcionar. E você experimentou o APIs Explorer. Não subestime
o APIs Explorer. Ele é uma ótima ferramenta para
testar APIs. E o uso dele não limita-se às suas
próprias APIs. Você pode usá-lo para qualquer API do Google.
Então, só coisas boas. Vamos falar agora sobre a autenticação de usuário.
Muitos aplicativos requerem que o usuário esteja registrado e
conectado antes de usar o aplicativo. Também vamos exigir
isso no Conference Central. Portanto, veremos como
fazê-lo. Antigamente, era normal
quase todo aplicativo criar seu próprio sistema de
gerenciamento do usuário. Isso significa que era necessário
escrever todo o código do zero para que os
usuários usassem o seu aplicativo. Que bom para nós
que isso não é mais necessário. Com o App Engine, você
pode usar a autenticação de terceiros com o Cloud Endpoints como, por exemplo
o Logon do Google+. Mas outras também podem
ser usadas. No Conference Central, exigiremos a conexão através da
conta no Google. Portanto, como saberemos que
o usuário está conectado na conta do Google quando
usa o Conference Central? Na realidade, isso é administrado
pelo Cloud Endpoints. Um método de API do Cloud Endpoints tem a opção de
aceitar um objeto usuário como o primeiro argumento.
Se o objeto usuário não for nulo,
o usuário é conectado. No entanto, se ele for nulo,
lançamos uma exceção que o cliente deve receber e
redirecionar para se conectar. Poderia ser mais fácil?
Você pode estar pensando agora: "E quanto à segurança
e à privacidade?" Bem, isso é administrado
pelo Logon do Google ou um provedor de autenticação de terceiros.
Portanto, esse mecanismo é a combinação do melhor dos dois mundos. Uma maneira simples
de adicionar a autenticação de usuário ao seu aplicativo, combinada com os fortes padrões
de segurança e privacidade do Google. Chega de falar por enquanto. É hora de você
codificar novamente, adicionando a
autenticação de usuário no Conference Central. Boa sorte.
恭喜你!你已做了许多事情 我们来
回顾一下 你编写了第一个代码行
并将其部署到 App Engine 你建立了会议中心
并进行运行 你试用了 API Explorer 不要小看
API Explorer 这是试用 API 时
使用的一款很棒的工具 它对你自有的 API 没有限制
可以将其用于任何 Google API
所以 都是好事情哦 但是现在 我们要来谈一谈用户身份验证
许多应用要求用户在使用
该应用前进行注册和登录 对于会议中心 我们也要求这样做
因此我们来看一看
我们该如何做到这一点?曾经有这样一个情况
每个应用都必须创建其
自有的用户管理系统 这意味着 你必须
从头编写所有代码 以便
你的用户可以使用你的应用 这对我们是有好处的
但现在不需要这样做了 通过 App Engine 你可以将第三方授权身份验证
与 Cloud Endpoints 一起使用
如 Google Plus sign-in 还可以使用其他
登录方式 在会议中心 我们还要求
使用 Google 帐户登录 因此
我们怎样知道用户在使用会议中心时
登录了其 Google 帐户 这实际上是
通过 Cloud Endpoints 实现的 Cloud Endpoint 的 API 方法可以选择
将用户对象作为其第一个参数
如果用户对象不为空
则使用户登录 但如果为空
则我们会发出异常拒绝登录
然后重定向到登录页面 可以更简单些吗?
嗯 现在你可以回答了 但是 安全和隐私
怎么样?嗯 所有操作都是
由 Google Sign in 或第三方身份验证提供者执行
所以此机制最好是进行合并 将添加用户身份验证
到你的应用的简单方法
与 Google 的安全和隐私标准进行合并
好了 不多说了 你通过将用户身份验证添加到
会议中心来再次进行编码吧 祝你好运!