The Anonymous User Pattern(roshfu.com)
roshfu.com
The Anonymous User Pattern
http://roshfu.com/2012/01/16/the-anonymous-user-pattern.html
11 comments
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.)
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.
Yup. That's what we do.
I like the original approach and the way an admin can impersonate a user is a nice win.
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.
wow that's a great idea, I hadn't thought of that! I guess that's just another benefit of dissociating the identity (Identity) from the login (User).
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.
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.
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'd love to get input on my way of doing it, btw - lazy signup has some unsolved UX challenges, I think)
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.
Great article, but that text shadow is horribly distracting. I'm a fan on header text, but not so much on main content.
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.
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.
(caution: dark side points)
(caution: dark side points)
I use something like this on FivePad[1]. Users get a "profile" record right away that gets attached to a "user" record as soon as they register.
[1]: https://www.fivepad.me
[1]: https://www.fivepad.me
We use the same approach on Feedity - http://feedity.com and offer users 'signup & save' option at the end of the flow.
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.