Cordova/Phonegap中的Firebase:从应用程序内使用电子邮件/密码登录? [英] Firebase in Cordova/Phonegap: Log in using Email/Password from within app?

问题描述

我正在从cordova应用程序运行Webview，并希望对用户进行身份验证，我知道他们具有OAuth策略，但我需要使用电子邮件/密码组合.

我想简化事情，但可能最终不得不生成令牌.

• 打开一个InAppBrowser，为Firebase加载身份验证流
• 使用此方法监听要完成的身份验证流程: https://www.firebase.com/docs/web/guide/user-auth.html

  然后我可以从该对象中获取所有信息，然后将其发送回cordova Webview，然后使用该信息填充该Firebase引用吗?

  解决方案

  Firebase极好的帮助中的一些答案:

  第一:

  您是正确的-任何人都可以提出注册请求，并且我们没有提供任何安全性来保护人们可以从中进行电子邮件/密码身份验证的网址.

  我们要求/启用OAuth身份验证而不是电子邮件/密码身份验证的源白名单的主要原因通常是围绕会话进行的.

  Firebase登录服务器不维护会话(通过cookie或任何其他方法)，因此向登录服务器请求密码验证.每个请求都需要一个用户凭证(密码).当恶意方利用用户的会话浏览器，即代表用户向某个页面发出请求(该页面由浏览器自动发送Cookie)时，CSRF通常是一种风险.

  此外，对于这些纯HTTP请求，我们还没有很好的方法来针对理想的基于源的白名单.我们可以使用CORS，但对于不支持JSON的较旧的浏览器环境，则必须使用JSONP.更为复杂的是，PhoneGap/Cordova应用程序根本没有相同的来源"概念，而且从服务器的角度来看，这些调用与任何发出具有相同标头的HTTP请求的恶意方是无法区分的./p>

  但是，OAuth提供者使用cookie进行会话，并且不需要用户为每个auth发明.要求.如果您批准了某个特定的Facebook应用程序，则该应用程序在下次请求您的数据时将不会显示任何UI/UX，也不会提示您-它不会显示.当我们执行OAuth时，我们永远不必将任何用户凭据发送到Facebook/Twitter/等等，因为这些凭据存储在facebook.com/twitter.com/etc的浏览器cookie中.我们需要保护的是一个恶意团体，冒充成为一个流行的，有效的Facebook应用程序.并利用这种短路行为，而这种行为将在用户不知情的情况下访问用户数据.

  我的答复:

  那么，如何确保它的安全?如果有人可以请求从cordova webview(不来自特定网址，仅来自应用程序本身)那么我不能保证人们可以从哪个网址进行注册?所以任何网站可以在配置中使用我们的网址"xxx.com"并开始注册用户?

  这对我来说似乎不正确.

  我认为我仍然需要将您列入白名单的外部网址伙计们.那将具有登录表单并进行身份验证.

  但是，我的问题是，我可以将该身份验证转移回我的cordova应用程序吗?我可以检查它在localStorage的某个地方吗?我必须进行一些测试.

  最后的回应:

  当然，我们很乐意为您提供帮助.我编写了许多原始的客户端身份验证代码，并且可以说出其中的设计决策和基本原理.如果您还有其他疑问，请务必告诉我.

  尽管我们不会将用户密码存储在Cookie中，但是我们会维护Firebase身份验证.LocalStorage中的令牌.我们的身份验证令牌由您唯一的Firebase机密签名(因此它们不能被欺骗)，并且可以包含任何对您的安全规则有用的任意用户数据.

  默认情况下，并且在使用委派登录(电子邮件+密码)服务时，这些令牌将仅包含一个用户ID，以唯一地标识您的用户，以供您在安全规则中使用.例如，您可以通过令牌中存在的用户ID(".write" ="$ uid = auth.uid")限制对给定路径的所有写入或读取(例如，写入/users/$ uid/name).有关该主题的更多信息，请访问我们的网站.

  您计划启动服务器以通过Amazon认证用户并生成令牌的计划听起来是正确的.对于希望使用我们不支持现成的身份验证方法(即Amazon OAuth)或具有自定义身份验证要求的用户，这是一种常见模式.注意:创建这些令牌并将其发送给客户端后，一旦您调用 ref.authWithCustomToken(…)，它们就会自动为您保留.只要该应用程序尚未过期，其后的重启将使用相同的令牌.

  I'm running a webview from a cordova app and want to authenticate a user, I know they have the OAuth strategies but I need to use the email/password combination.

  I'd like to keep things simple but may end up having to generate a token.

  • Open an InAppBrowser that loads an auth flow for firebase
  • Listen for that auth flow to be completed using this method: http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
  • Grab the result from the webview again and insert it into the webview firebase instance

  I'm guessing that's not possible due to security.

  My app is using Amazon login (required) so my alternative would be:

  • webview loads InAppBrowser with our external url
  • that loads Amazon auth, then generates a token for Firebase
  • webview listens for token and grabs it, stores it in localstorage

  Edit: In the firebase docs on logging in with a username/password, I see it returns a token for the session and more information in the authData object: https://www.firebase.com/docs/web/guide/user-auth.html

  Could I then take all the information from that object and send it back over to the cordova webview and then populate that Firebase ref with the information?

  解决方案

  Some answers from the wonderfully helpful support at Firebase:

  First:

  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.

  My response:

  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.

  And final response:

  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/Phonegap中的Firebase:从应用程序内使用电子邮件/密码登录?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！