There are many places where we are dealing with anonymous users. Currently this is hardwired into comment module, let's abstract the functionality.

Comments

Dave Reid’s picture

I assume this means this involves the "remember the user's name and e-mail" functionality?

catch’s picture

David 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

webchick’s picture

IMO 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.

webchick’s picture

Oh, well hooray for David Rothenstein then! ;)

Dave Reid’s picture

Issue tags: +anonymous users

Hooray indeed!

quicksketch’s picture

This 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.

eaton’s picture

Issue #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.

chx’s picture

Today'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').

moshe weitzman’s picture

I'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.

chx’s picture

As 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.

sun’s picture

I'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.

webchick’s picture

What 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?

joachim’s picture

+1 and subscribing.
Lots of modules need to identify anon users: simplenews, ubercart, VotingAPI to name a few biggies.

sun’s picture

Version: 7.x-dev » 8.x-dev
larowlan’s picture

+1 and subscribing

chx’s picture

This would be best handled by adding an anonymous user bundle to the user module. A lot of problems would go away.

moshe weitzman’s picture

I 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.

sun’s picture

Does 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:

  1. Reads/Writes on the {users} table will heavily increase.
  2. We'll technically need a general uid 0 account in {users}, in addition to visitor-specific rows, since views and stuff need something to join and filter on.
  3. Turning anonymous user fields into real fields of a bundle that applies to all anonymous visitors makes sense.
  4. Certain sites may not have a use-case for storing anonymous/visitor data.
moshe weitzman’s picture

1. 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.

joachim’s picture

> 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.

chx’s picture

Um. 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.

joachim’s picture

Heh, 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 ;)

catch’s picture

The 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.

joachim’s picture

I wonder whether this is something that could be tried as a contrib module on D7...

joachim’s picture

> 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.

Dries’s picture

Issue tags: +Favorite-of-Dries

Tagging.

IceCreamYou’s picture

Related: 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.

andrewbelcher’s picture

I 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.

cweagans’s picture

cweagans’s picture

Actually, 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.

juan_g’s picture

There 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. ;)

Welcome unregistered editing

On Wikipedia, unregistered editing, also known as IP editing and incorrectly as "anonymous editing", is the editing of Wikipedia pages while not logged in. When such an edit is made, the IP address associated with the present connection will be permanently recorded in the edit history of the page that has just been edited.

While having a username has a lot of benefits, editing already existing pages without one is perfectly acceptable, and in fact, is very much welcomed.

Wikipedia: Welcome unregistered editing

Unregistered users

Contributors who have not created an account or logged in are identified by their IP address rather than a user name, and may read all Wikipedia pages (except restricted special pages), and edit pages that are not protected or semi-protected.

Wikipedia: User access levels: Unregistered users

larowlan’s picture

Fwiw action occuring over in #1806514: Unify anonymous and registered users one of these is a duplicate surely?

cweagans’s picture

Status: Active » Closed (duplicate)

No patch or plan of action here, so even though this one is older, let's mark it as a dupe.

yautja_cetanu’s picture

I 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.