Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There are many places where we are dealing with anonymous users. Currently this is hardwired into comment module, let's abstract the functionality.
Comments
Comment #1
Dave ReidI assume this means this involves the "remember the user's name and e-mail" functionality?
Comment #2
catchDavid Rothstein is working on an approach to comment notifications which is likely to add a 'visitor' table - that could get us quite a lot of the way towards the username/e-mail stuff http://drupal.org/node/322064#comment-1189887
Comment #3
webchickIMO this means something a bit more; a consistent way to deal with ALL site visitors, whether they be anonymous or have an authenticated user account behind them. I would love to see a sensible way of dealing with this in core. Far too many modules need to do many many lines of special-case handling to stop Drupal from assuming all anonymous users are the same person because they share the same user ID. We have a number of open feature requests and bug reports even in the core queue about the fact that some modules work horribly when anonymous users are given permissions to use them.
We wrote http://drupal.org/project/visitor for a project recently to get around the "all anonymous users are uid 0" problem. Our use case was that we'd have both authenticated and anonymous users using the site to download files, but the we wanted the download tracking and abuse prevention to work the same across the board. It tracks visitors by session ID rather than user ID, which persists until they clear their cookies.
I haven't checked recently to make sure that what we have in SVN is the same as what's on cvs.drupal.org (things got crazy with the site launch, etc.), but at least 80% of the module is there if anyone wants to take a look.
Comment #4
webchickOh, well hooray for David Rothenstein then! ;)
Comment #5
Dave ReidHooray indeed!
Comment #6
quicksketchThis sounds the same as #360705: Add wrapper layer around authenticated and anonymous users so that they can be treated as one and the same. Session API is indeed a good place to start, as they have already abstracted this into an API used by multiple modules.
Comment #7
eaton CreditAttribution: eaton commentedIssue #360705 explicitly requested that an API allow modules to treat 'visitors' in the same way whether they're registered or unregistered. We had to build a system like that for a client site recently, and it worked smoothly -- 'visitors' could be identified by visitor_id, and unless they cleared their cookies, everything persisted. If they created a user account, the visitor_id became 'set in stone' and was forever associated with their user account, ensuring that any 'visitor' references would continue to work for them.
It's not an ideal solution if we're committing to solving the problem in core, but there are a couple other similar approaches starting to appear. #360705 mentioned Session API, Visitor, and Lazy Registration.
Comment #8
chx CreditAttribution: chx commentedToday's discussion on #drupal-dev summed up: a) rename status to active b) add a new status column which a string. Comment module then adds users which are not active (blocked) and the status is $result_of_bikeshedding (we can start with 'anonymous commenter').
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedI'm still a little confused. What will the 'active' column hold for an anonymous commenter? Also, I can't really get behind user.module offerring a free form field whose value is only understood by other modules. In this example, only comment module knows what anonymous commenter is. The field should live in a new comment_uid table, or comment.module can schema_alter the new column into users. Won't modules fight over this column? Surely there is more than one piece data that we want to track about anon users.
Comment #10
chx CreditAttribution: chx commentedAs an anonymous commenter is not an active (ie visible and login-able user) it's blocked. Also, i do not know why it is a problem if other modules write various things into a user.status column... it's pointless to move to a separate module because any time you have a more complicated registration form you want to use the status to note where the user is in that process. And because we still have the active column, we can easily still run Views over users, listin' only active users.
Comment #11
sunI'd be +1 for moving this: #324743: Puzzle pieces into core. Make Comment module use it to attach anonymous user (visitor) data, still bound to Comment module in a first step, but potentially movable into more generic visitor object fields later on.
Comment #12
webchickWhat chx proposes here is basically the approach outlined in the Visitor module queue, but turns the user table into the visitor table (so it stores both authenticated and anonymous details in the same place). Works for me.
However, the proposed new user.status column screams red flag to me. I can see that being totally abused by every module under the sun. Furthermore, I don't think a single string is representative enough for all of the possible ways to describe a user.
What if we just add a -1 to user.status that means "anonymous" and add the session ID column to the user table?
Comment #13
joachim CreditAttribution: joachim commented+1 and subscribing.
Lots of modules need to identify anon users: simplenews, ubercart, VotingAPI to name a few biggies.
Comment #14
sunComment #15
larowlan+1 and subscribing
Comment #16
chx CreditAttribution: chx commentedThis would be best handled by adding an anonymous user bundle to the user module. A lot of problems would go away.
Comment #17
moshe weitzman CreditAttribution: moshe weitzman commentedI had to mull over chx' terse comment to understand what he means. Here my take ...
We start saving anon users who fill out the comment form and do other interesting stuff (shopping cart) as real accounts in the users table. We add a column to the users table called bundle which is analogous to the type column in the node table. All of these anon users have a value of 'anonymous user'. All authenticated users get - something else. I vote for the name of their primary role (roles have weights in D7).
All of the extra fields that folks want to store about anon like 'homepage' get added as a Field to the 'anonymous user' bundle.
uid=0 would probably still be around for all those visitors that don't merit a user account.
Comment #18
sunDoes it really make sense to mix registered user accounts with anonymous user "accounts"/data in a single db table?
Thoughts in random order about that:
Comment #19
moshe weitzman CreditAttribution: moshe weitzman commented1. reads and writes will not increase for most sites. you only get a record in users once you do something extraordinary like complete an anon comment form or put stuff in your shopping cart.
2. yes
3. yes
4. yes. see #1.
chx points out that my proposal to bundle authenticated users by their primary role is problematic since roles and role assignments are volatile. perhaps we can make it work though.
Comment #20
joachim CreditAttribution: joachim commented> chx points out that my proposal to bundle authenticated users by their primary role is problematic since roles and role assignments are volatile. perhaps we can make it work though.
So just have a second bundle called 'authenticated user', whose main purpose is to not be 'anonymous user'.
> Does it really make sense to mix registered user accounts with anonymous user "accounts"/data in a single db table?
Yeah, I do feel slightly icky as well at the idea of the user table filling up with anyone who clicked a votingAPI widget, say.
Comment #21
chx CreditAttribution: chx commentedUm. I find this argument largely outdated. Disk storage is pracitcally free these days. You can very easily store tens of millions of rows in a table even on slightly older hardware. Dont forget that btree indexing has a O(log n) cost for SELECT, ie a million rows only need 20 comparisons. Ten million is only 23. Ten million records if each record takes a kilobyte is only 10GB. And so on.
Comment #22
joachim CreditAttribution: joachim commentedHeh, I didn't say it was rational! :D
I'm slightly fussy about IDs... hate it when I have to delete node 1 on a site and the front page ends up being node 27 or something. Call it mild Drupal-OCD ;)
Comment #23
catchThe current core uses for this like anonymous comments or shopping cart purchases, these don't bother me too much because they're quite active activities, and having a single record by e-mail for me@example.com in the users table is actually /less/ storage than putting it with each comment.
However there are real issues here in terms of impersonation etc. - if ten different people use the same e-mail address in an anonymous comment - possibly with different 'names' or homepages, which one is going to be used as the canonical version?
Revisions might help, but that's still going to change what gets displayed for each comment - so say 'Bob' leaves a tonne of anonymous comments on someone's blog, then later a spammer comes along and uses his e-mail address, putting 'byviagranow' as the 'name', suddenly all of Bob's comments look like they were posted by 'byviagranow'. You could add revisions to users, and for these anonymous accounts, but that wouldn't solve this issue either unless anonymous comment display was querying revisions, which'd be a bit odd as well.
. There's also the question of whether we leave it open for people to 'claim' anonymous user posts after logging in - and if we don't, then we'd need to remove all unique constraints for e-mail addresses on the user table.
So it's potentially a very good idea, but implementation could be a bit sticky.
Comment #24
joachim CreditAttribution: joachim commentedI wonder whether this is something that could be tried as a contrib module on D7...
Comment #25
joachim CreditAttribution: joachim commented> There's also the question of whether we leave it open for people to 'claim' anonymous user posts after logging in
This sort of problem already exists in core D7: #472202: 'Name' value for anonymous comments can conflict with registered usernames.
Comment #26
Dries CreditAttribution: Dries commentedTagging.
Comment #27
IceCreamYou CreditAttribution: IceCreamYou commentedRelated: https://drupal.org/project/sup
This module basically keeps track of what anonymous users do and assigns all their content to their user account once they register. It's been a long time since I worked on it and there are some rough spots but thought it might be useful/interesting.
Comment #28
andrewbelcher CreditAttribution: andrewbelcher commentedI would love to see some of this. My angle is quite different though. I'm one of the people working on Party and one of the bit headaches of building a CRM on Drupal is the issue around users, specifically non-user users (which is a very similar problem to multiple anonymous users). One of the issues is that everything in Drupal currently relates to a user record, but if you're building a CRM you may want to connect things to what we've dubbed as 'parties' (ie some kind of single entity that closest maps to a user, but doesn't necessarily authenticate on the site).
Our solution is to have a separate record of parties, and then attempt to have a bridge to a user account from the party. We then need to try and map everything to a party rather than a user, which can sometimes be awkward. However, if anonymous users could each have their own record the the database, we could ditch the complicated work around and focus on building really useful CRM functionality.
I think this also fits in with making Drupal an even better base as a framework/building tool, widing the potential users, supporters and contributors for it.
Comment #29
cweagansRelated: #335411: Switch to Symfony2-based session handling
Comment #30
cweagansActually, cosmicdreams tells me that 335411 will provide a wrapper around anonymous users, so this is potentially a duplicate. Leaving this issue open for now at his request.
Comment #31
juan_g CreditAttribution: juan_g commentedThere is also an alternative, very simple solution with no need for session IDs, no need for anons' cookies, etc.: The Wikipedia system for anonymous users.
Basically, the overwhelming success of Wikipedia came from making it extremely easy for anyone to quickly contribute to the edition of articles, even without registering for an user account.
For example, ten years ago I began to contribute to Wikipedia because from the start it was so simple, just writing and clicking a button, no need to register, etc. So, my first edits are recorded with just an IP number, before I had a human account. ;)
Comment #32
larowlanFwiw action occuring over in #1806514: Unify anonymous and registered users one of these is a duplicate surely?
Comment #33
cweagansNo patch or plan of action here, so even though this one is older, let's mark it as a dupe.
Comment #34
yautja_cetanu CreditAttribution: yautja_cetanu commentedI don't mind this being marked as a duplicate but the reason why we created a new issue rather then continue it here is because our original issue was about doing 1 thing specifically. Taking the Account/Authentication stuff out of User. As a result of doing that change it would have a bunch of different consequences making things like an "anonymous user api" simple, also provide pluggable authentications potentially and make CRM system simple.
My hope was to get a patch and plan of action agreed in that separate issue and then we could go through the related issues and show how they change as a result of our patch.