I tried this with BCC. It ended up being a colossal support expense to have guest accounts available as an option, and didn't lead to meaningful revenue. (Literally less than $100 in about 6 months.) I had every possible variation of "I used it at home and now I am using it at school and the evil computer lost all of my work!!1 FIX IT NOW!", despite telling people multiple times that exactly that would happen if they didn't put in an email address.
It is entirely possible that my implementation sucked or my customers are just uniquely ... inexperienced with dealing with novel usage paradigms, but test the heck out of this.
Why not just create a User model that has a null username and password field? If they sign up, you fill in those attributes. No need for a second table!
This is the first question that came to my mind too. And it feels like a more accurate model of reality, since an anonymous user is a user, just without a username/password.
You could model this in other ways on the User model too, like having a registered_at column, which, when blank, means an unregistered user. (In case, for example, you wanted to autogenerate a username for anonymous users, for display purposes.)
That's a good point, I just thought the model of having the identity be separate from the login credentials made more sense. It has some nice benefits to separate them mentioned by ch below.
Seems with this approach it should be easy for an admin to 'su' to a normal user account and perform actions as that user. Nice for tech support and other administrative operations.
This is typically why you separate authentication and authorization. In your case many authenticated users can be authorized to access a single identity.
How would you divide the two? I'd say that 'identity' and 'user' are the same, that the things you'd want to dissociate are the ('roles' | 'permission set' | 'authorization rules') from the ('identity' | 'user' | 'login').
But in that case, it wouldn't help with anonymous sessions - unless you'd just define those as new 'identities' with many of the properties set to unknown.
I think the pattern is interesting enough to flesh out, but I'm not convinced yet if it's a real change from the traditional user/permission duality that is already in wide use.
We tried this for a healthcare Q&A site we built (under the assumption that anonymity was paramount).
We blocked spam bots the best we could, but still had issues with actual human spammers and a general lack of quality of submitted posts.
Pros: Questions submitted increased by almost 3x's
Cons: Quality of questions / answers decreased considerably. Threatened the integrity of our overal experience so we removed it.
I do this with my site, http://www.manabi.org to let users try reviewing Japanese flashcards before signing up. They can do everything a normal user can except for share their potentially spammy content with other users.
I wonder how you prevent bots from creating millions of fake users. I guess by looking at the headers for their user agent and have a blacklist of known bots?
it's the same problem as allowing users to create millions of identities. if it gets to be a problem, you can just start removing unclaimed identities from oldest to newest.
I wonder what benefits localStorage would have over cookie based sessions in enabling anonymous usage over longer periods of time. Are user behaviors for clearing localstorage different from cookies?
Seems like an interesting thing to test on my new project.
Tangentially, but you might also be interested in evercookie (http://samy.pl/evercookie/) which exploits the fact that browsers have made clearing cookies, localStorage, and a few other things into separate tasks, so the probability of users correctly clearing everything is low.
it would be interesting to know how this affects the bottom-line across businesses. e.g. IMO, this will not work in the games industry.
Anyone has any experience implementing this to share?
It is entirely possible that my implementation sucked or my customers are just uniquely ... inexperienced with dealing with novel usage paradigms, but test the heck out of this.