views:

51

answers:

2

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.

+1  A: 

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
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
+1  A: 
Mike