-4

Suppose you're developing an independent, small sub-page for a big and well frequented web portal.

The sub-page shows entries from a public event calendar, and allows users to highlight those especially interesting to them. The highlighted events shall be highlighted (and maybe shown on a separate list) on each future visit of that user.

However, building a classical user registration system, or any other way of storing the user-highlighted event picks on the server, is not an option: The sub-module needs to be as self-contained and need as little maintenance as possible. It's one of the conditions of the project.

The only way to do this without building a login system of some sort (as far as I can see) is using cookies or some other local storage (Flash / HTML 5....) which has the obvious and big downside that it's tied to the computer, not the user.

Is there a way of storing a few kilobytes data on a per-person basis, but without having to utilize a login or openID, that I am overlooking? A reliable web service perhaps?

A "key/value" storage service, to which I pass a unique key (one that the user specified) and get the savedvalue in return, would be sufficient. There is no need for real security - the data in question is by no means confidential.

OpenID is not an option: It is not well known enough among the audience of the site.

Facebook would be an option, but I don't think they provide "storage" options like this.

As a workaround, I am contemplating offering the user their event picks as a text file download, that also can be uploaded and turned into cookies on another machine. But that is pretty complicated for the user, and thus not perfect.

Pekka
  • 442,112
  • 142
  • 972
  • 1,088
  • 1
    OpenID does not offer any storage functions either, so it couldn't be used. Anyway, there is no way to store per-user data client-side. You can't store data on a client and then except that it will magically show up on another computer. Maybe you could just store the data in text files on server? – Mewp Aug 19 '10 at 08:37
  • @Mewp yeah, I was referring to OpenID for building a very light-weight storage system locally. I'm not looking for client-side ideas obviously, for the reason you state. Text files (or setting up a tiny data base after all, sigh) may indeed be the way to go. – Pekka Aug 19 '10 at 08:40
  • For clearification: is the issue finding a portable authentication mechanism / uniqueID to the data storage **or** is the issue implementing the data storage itself? – Gordon Aug 19 '10 at 08:42
  • Am I getting you right that you do not get a user id or anything passed on from the page that's including your sub-page? – Nicolas78 Aug 19 '10 at 08:43
  • Instead of a plain text file you could at least send an iCalendar file. Many application and even cell/smart phone support that format. http://en.wikipedia.org/wiki/ICalendar – VolkerK Aug 19 '10 at 08:46
  • @Gordon the main issue (although probably illusionary) is getting around having to run the data storage on the server, for maintenance reasons. I.e. finding a reliable web service that can do the storing for me, either using a login mechanism the user uses already anyway (Facebook) or using an insecure key the user specifies ("pekka1980"). Failing that, the question would be for implementations of server-side key/value storage that are as little maintenance-intensive as possible. As far as I can see, though, the easiest thing here is going to be a small mySQL table. @VolkerK great idea! – Pekka Aug 19 '10 at 08:49
  • @Pekka I think what you are looking for is something like Digg or FB's I Like Button for i/h/vCal items. Unfortunately, I am not aware of a service that does this (maybe Google Calender). But like Volker suggested, you could at least serve them like that so users can import them to their own calendars. That wouldnt solve the highlighting issue though. – Gordon Aug 19 '10 at 08:53
  • If you can get the user to provide a unique ID of some variety, perhaps you could use the [Google Docs API](http://code.google.com/apis/documents/) to create a document which contains the settings for each user. That is, rather than each user having to have a separate Google account, your application has a single account which contains multiple documents - one per user. It depends how secure it needs to be... – Mike Aug 19 '10 at 08:57
  • @Gordon yeah, exactly! The iCal approach would somewhat solve the highlighting issue if users can re-import the calendars, writing back the highlighted events into a cookie or local storage. But it's kludgy. Thanks for mentioning Digg/FB's "like" buttons, hadn't thought of those! I *could* represent an event as a URL - if I can read back the "like" status from FB programmatically, that would solve it. I'll look into that. – Pekka Aug 19 '10 at 08:57
  • @Mike very, very interesting idea, too! Especially the Google Spreadsheets API. I fear that they have access rate limits that would make this difficult, but I'll check it out. – Pekka Aug 19 '10 at 08:58
  • @Mike why not make your comment an answer for future generations? – Pekka Aug 19 '10 at 09:06
  • @Pekka: I was wondering the same thing myself ;-) I was just following the trend, which appeared to be the use of comments instead of answers... I'll add it as an answer now. – Mike Aug 19 '10 at 09:12

2 Answers2

1

We have a similar system on our site, where users can bookmark pages to a planner/wishlist function. The saved items are sent via a webservice and stored on our server, and there is a corresponding get webservice.

We have a 'lazy register' system. The first time a user saves an item, they are asked for their email (but no password, as nothing is confidential). This is hashed and saved locally using a cookie, then used to set/get the saved items. When the user uses a different computer they are again asked for their email.

The key is that a register and a login are the same operation, so there is no need for any password reminders or any reset functionality.

Adam Hopkinson
  • 28,281
  • 7
  • 65
  • 99
  • Yup, this is probably what I'm going to end up with, too. I'm checking first whether there is any way of not having to store the data on the application's server (but with a Google API or on the user's Facebook account or whatever) but maybe a simple solution like this is the best way to go. – Pekka Aug 19 '10 at 09:01
1

The Google Docs API provides programmatic access to Google Docs, where you can create and store documents and spreadsheets. Your application could have its own Google login, which it uses to create one or more documents per user. These documents could be used to store the user settings.

Provided you can get a unique ID from each user (an email address, or something more secure, perhaps), this should be fairly simple. You can even organize the files into folders—one per user.

Alternatively, you could combine Google Docs with the Google Spreadsheets API, where I have just noticed this rather handy feature:

Tables & Records
Interact with spreadsheets as if they're a database using Tables and Records.

Mike
  • 21,301
  • 2
  • 42
  • 65