3

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!

Community
  • 1
  • 1
Van Coding
  • 24,244
  • 24
  • 88
  • 132
  • I've got the same question. I wonder why there has been no answer yet. Thus: Here's a bounty. And btw, I'd also be interested in persisting more than just some config data. For instance, I would like to do some real db stuff like logging, tracking etc. Thanks for whatever answer – Ta Sas May 29 '12 at 16:37
  • You should add the tags of the language you want it in. – 472084 May 29 '12 at 16:42

2 Answers2

1

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.

jzonthemtn
  • 3,344
  • 1
  • 21
  • 30
0

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:

  • Redis - An open source NoSQL database.

  • Google Storage for Developers - Store data on Google's infrastructure using a REST interface. It's a paid service, but it's probably the closest thing to what you're looking for since it's part of the Google API Console.

jamesmortensen
  • 33,636
  • 11
  • 99
  • 120