Cordova/Phonegap 中的 Firebase：从应用内使用 Email/Password 登录？
Firebase in Cordova/Phonegap: Log in using Email/Password from within app?
我是 运行 来自 cordova 应用程序的 webview，想对用户进行身份验证，我知道他们有 OAuth 策略，但我需要使用 email/password 组合。
我想让事情变得简单，但最终可能不得不生成一个令牌。
- 打开 InAppBrowser 加载 firebase 的身份验证流程
- 使用此方法侦听要完成的身份验证流程：http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
- 再次从 webview 中抓取结果并将其插入到 webview firebase 实例中
出于安全考虑，我猜这是不可能的。
我的应用正在使用亚马逊登录（必需），所以我的替代方案是：
- webview 使用我们的外部 url
加载 InAppBrowser
- 加载 Amazon 身份验证，然后为 Firebase 生成令牌
- webview 监听 token 并抓取它，存储在 localstorage
编辑：
在关于使用 username/password 登录的 firebase 文档中，我看到它 returns 是会话的令牌，在 authData 对象中看到更多信息：
https://www.firebase.com/docs/web/guide/user-auth.html
然后我可以从那个对象中获取所有信息并将其发送回 cordova webview，然后用这些信息填充那个 Firebase ref 吗？
这也是我感兴趣的话题，因为我已经实现了类似的东西，twitter 数字（原生 android）+ webview 中的 firebase 自定义登录。
我认为，按照 firebase 的建议，您可以使用其他身份验证提供程序，然后使用 firebase 自定义登录。
您是否使用 android 本机代码中的亚马逊登录？如果在登录后是这样，则为 firebase 生成一个 JWT 令牌并使用它来访问 firebase。
如果所有代码都在 Html/js 应用程序中，那么也许您可以使用自定义登录并在确保其登录到亚马逊后在您的服务器上生成一个令牌。
Android 混合应用程序的问题如下：JWT 令牌（用于 firebase）应该在安全系统（例如服务器端）上创建，而不是 android java代码，混合应用程序的另一个选项是执行 http 请求以生成令牌，但我发现安全性较低，任何人都可以通过找到 URL 来获得令牌，而不是在 android 应用程序代码，您可以在发布新版本时更改令牌的安全性 key/seed。
综上所述，我认为firebase没有研究移动混合应用的问题。
来自 Firebase 非常有用的支持的一些答案：
第一个：
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
我的回复：
So, how is that secured? If anyone can make a request to sign up from a
cordova webview (which comes from no specific url, just the app iteself)
then I can't secure from which url people can sign up from? So any site
could use our url "xxx.com" in their config and start registering
users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you
guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app?
Is it somewhere in localStorage I can check? I'll have to run some tests.
最终回复：
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.
我是 运行 来自 cordova 应用程序的 webview，想对用户进行身份验证，我知道他们有 OAuth 策略，但我需要使用 email/password 组合。
我想让事情变得简单，但最终可能不得不生成一个令牌。
- 打开 InAppBrowser 加载 firebase 的身份验证流程
- 使用此方法侦听要完成的身份验证流程：http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
- 再次从 webview 中抓取结果并将其插入到 webview firebase 实例中
出于安全考虑，我猜这是不可能的。
我的应用正在使用亚马逊登录（必需），所以我的替代方案是：
- webview 使用我们的外部 url 加载 InAppBrowser
- 加载 Amazon 身份验证，然后为 Firebase 生成令牌
- webview 监听 token 并抓取它，存储在 localstorage
编辑：
在关于使用 username/password 登录的 firebase 文档中，我看到它 returns 是会话的令牌，在 authData 对象中看到更多信息：
https://www.firebase.com/docs/web/guide/user-auth.html
然后我可以从那个对象中获取所有信息并将其发送回 cordova webview，然后用这些信息填充那个 Firebase ref 吗？
这也是我感兴趣的话题，因为我已经实现了类似的东西，twitter 数字（原生 android）+ webview 中的 firebase 自定义登录。
我认为，按照 firebase 的建议，您可以使用其他身份验证提供程序，然后使用 firebase 自定义登录。
您是否使用 android 本机代码中的亚马逊登录？如果在登录后是这样，则为 firebase 生成一个 JWT 令牌并使用它来访问 firebase。 如果所有代码都在 Html/js 应用程序中，那么也许您可以使用自定义登录并在确保其登录到亚马逊后在您的服务器上生成一个令牌。
Android 混合应用程序的问题如下：JWT 令牌（用于 firebase）应该在安全系统（例如服务器端）上创建，而不是 android java代码，混合应用程序的另一个选项是执行 http 请求以生成令牌，但我发现安全性较低，任何人都可以通过找到 URL 来获得令牌，而不是在 android 应用程序代码，您可以在发布新版本时更改令牌的安全性 key/seed。
综上所述，我认为firebase没有研究移动混合应用的问题。
来自 Firebase 非常有用的支持的一些答案：
第一个：
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
我的回复：
So, how is that secured? If anyone can make a request to sign up from a cordova webview (which comes from no specific url, just the app iteself) then I can't secure from which url people can sign up from? So any site could use our url "xxx.com" in their config and start registering users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app? Is it somewhere in localStorage I can check? I'll have to run some tests.
最终回复：
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call
ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.