在 Google 帐户中保存设置

发布于 2024-12-01 03:48:17 字数 346 浏览 0 评论 0原文

OpenID 是个好东西,但我仍然必须将用户设置存储在我自己的服务器上。我正在创建一个小应用程序,它只有一些可以存储在 JSON 文件中的设置。 有没有办法将此类数据存储在 Google 帐户中?

我已经找到了这个: 在用户的 Google 帐户上存储数据

因此,我知道这会可以将此类数据存储在文档中。但是......我想让这些数据远离用户。他不应该看到包含我的 JSON 数据的文档。 有人知道另一种更专业的方法吗?

感谢您的回答!

OpenID is a nice thing, but i still have to store the users settings on my own servers. I´m creating a little App that has only has a few settings which can be stored in a JSON file.
Is there a way to store such data in a Google Account?

I already found this:
Storing data on a user's Google's account

So, I know that it would be possible to store such data in a document. But... I want to keep this data away from the user. He shouldn´t see a document, which contains my JSON data.
Does somebody know another, more professional way?

Thanks for your answers!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

靑春怀旧 2024-12-08 03:48:17

参考您问题中的链接,将信息存储在用户的 Google 帐户中和存储在其 Google 文档(或现在的 Google 云端硬盘)中的文档中是两件不同的事情。文档就是这样,用户可以自由更改或删除它。我不喜欢一个应用程序将我的 Google 文档视为某种形式的 INI 文件或注册表项以存储用户数据。

无法在其 Google 帐户本身内存储任何信息。 OpenID 用于身份验证。

您必须维护自己的用户数据数据库才能实现所描述的目标。根据您的实施限制,AWS SimpleDB 或 DynamoDB、SQL Azure 或 Google AppEngine 是提供用户数据存储方法的一些产品。

Referring to the link in your question, storing information inside a user's Google Account and inside a document in their Google Docs (or Google Drive now) is two different things. A document is just that, and the user is free to change or delete it. I for one would not like an application that treated my Google Docs as some form of an INI file or registry key for the purpose of storing user data.

You will not be able to store any information inside their Google Account itself. OpenID is used for authentication.

You will have to maintain your own database of user data in order to meet the described goal. Depending upon your implementation restrictions, AWS SimpleDB or DynamoDB, SQL Azure, or Google AppEngine are some of the offerings which provide a means for user data storage.

半山落雨半山空 2024-12-08 03:48:17

OpenID 的存在使得应用程序可以使用大型、完善的实体(例如 Google)来处理用户身份验证,以便应用程序开发人员可以专注于其他任务。根据您的问题,您的目标就是做到这一点,将数据存储问题转移给第三方,以便您可以专注于您的产品并避免重新发明轮子。

然而,OpenID 并不是这样工作的。如您所知,这个想法是将身份验证过程(并且仅是身份验证过程)外包给第三方。 OpenID 应该做的不多也不少;它要么回答“是的,我们知道这个人就是他/她所说的那个人”,要么回答“不,我不认识这个人”。

将应用程序数据存储在 Google 帐户中会有点违背 OpenID 的目的,而且我看不到任何 OpenID 提供商违反此标准。

解决您的问题

话虽如此,我有两个解决方案向您提出,虽然它们不完全您正在寻找的东西,但它们实际上确实如此解决您的问题并让您专注于打造您的产品和品牌。

Bigtable-JS:

Bigtable-JS 是一个由 Chris Thatcher 维护的项目。它是一个在 Google App Engine 上运行的 RESTful JSON 数据库。您无需了解 Python 或 Java 即可使用它,因为它旨在接受 HTTP GET、POST、PUT 和 DELETE 请求,以便在高度可扩展的 Google App Engine 数据存储区中轻松检索和存储数据。

该项目已经两年没有更新了,但考虑到它只是存储 JSON 字符串,维护工作很可能是最少的。

此外,由于您的数据存储需求很少,只要有适量的缓存,您就可以在不超过 Google App Engine 的免费配额的情况下进行操作。

此开源项目可在 GitHub 上获取

Blogger

可以肯定地说,当大多数人想到 Google Blogger 时,他们就会想到博客?但 Google Blogger 团队的两位成员 Brett Morgan 和 Pat Coleman 似乎不这么认为。

他们在 2011 年 Google IO 大会上发表了 42 分钟的演讲,标题为 Google I/O 2011:构建商业网络在使用 Blogger API 的展示中,他们概述了如何使用 Blogger API 构建电子商务和移动网站,利用 Google 的基础设施,同时还使用经过试验和测试的 API。

方法来使用 API:

  • 他们在演示中展示的网站看起来一点也不像 Blogger,这是因为他们超越了博客,而是采用了更抽象的
    • 帖子标题
    • 帖子作者
    • 发布日期
    • 发布正文
    • 发布标签
    • 发表评论

这些实际上只是幕后的分组,您的应用程序不需要关心它是否将数据存储在帖子正文或其他文本变体中。 REST 的强大之处在于接口在两个系统之间提供的分层,使它们能够自由地做自己最擅长的事情。

由于您只是存储 JSON 字符串,因此您可以使用 Blogger API 将该字符串存储在帖子正文中,并将博客设为私有,以便数据在 Google 基础设施中得到安全保护。

摘要

虽然这两种解决方案都不允许您将数据存储在用户的 Google 帐户中,但这两种解决方案都可以让您自由地将开发工作集中在其他任务上,并将数据库管理任务留给云端。

您可能需要考虑的其他解决方案如下:

OpenID exists so that applications can use a large, well-established entity, such as Google, to handle user authentication so that the application developer can focus on other tasks. Your goal, based on your question, is to do exactly that, offload data storage concerns to a third party so that you can focus on your product and avoid reinventing the wheel.

However, OpenID doesn't work like this. The idea, as you know, is to outsource the authentication process, and only the authentication process, to the third party. OpenID is supposed to do no more, no less; it either responds with "yes, we know this person is who he/she says he/she is" or "No, I do not know this person".

To store application data in a Google account would sort of defeat the purpose of OpenID, and I can't see any OpenID provider breaking this standard.

Solutions to Your Problem:

With that said, I have two solutions to propose to you that, while they aren't exactly what you're looking for, they do in fact solve your problem and allow you to focus on building your product and your brand.

Bigtable-JS:

Bigtable-JS is a project maintained by Chris Thatcher. It's a RESTful JSON database that runs on Google App Engine. You need not know Python or Java to work with it, as it's designed to accept HTTP GET, POST, PUT, and DELETE requests to simply retrieve and store data in the highly scalable Google App Engine datastore.

The project hasn't been updated in 2 years, but considering it's just storing JSON strings, it's quite possible that maintenance is minimal.

Also, since your data storage needs are light, with the right amount of caching, it is quite feasible that you could operate without exceeding Google App Engine's free quotas.

This open source project is available on GitHub.

Blogger:

Is it safe to say that when most people think of Google Blogger, they think of blogs? Well, Brett Morgan and Pat Coleman, both members of the Google Blogger team, seem to think otherwise.

In their 42 minute presentation at the 2011 Google IO Conference titled, Google I/O 2011: Building a Business Web Presence using Blogger APIs, they outline how they use Blogger API's to build ecommerce and mobile websites, capitalizing on Google's infrastructure while also using tried and tested API's.

The websites they show in their demos look nothing like Blogger, and this is because they looked beyond blogs and instead took a more abstract approach to using the API's:

  • Posts
    • Post Title
    • Post Author
    • Post Date
    • Post Body
    • Post Tags
    • Post Comments

These are really just groupings under the hood, and your app need not care whether it's storing data in a post body or some other text variant. The power of REST is in the layering that the interface provides between the two systems that frees them both up to simply do what they do best.

Since you're just storing a JSON string, you could conceivably store that string in a post body using the Blogger API's, and make the blog private so that the data is safely secured in Google's infrastructure.

Summary:

While neither of these solutions will allow you to store data in a user's Google Account, both of them offer you the freedom to focus your development efforts on other tasks and leave the database administration tasks to the cloud.

Other solutions you may want to consider are as follows:

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文