Allow anonymous users to flag content

I was able to achieve this by commenting out lines 636-638, 184-186, and modifying line 448 to

Sorry, I don't know how to make a patch file.

Because of the way flag keeps a status on flagging, allowing flags for anonymous users won't work quite the way you expect. That is, all the anonymous users on the entire site basically count as a single user. A piece of content flagged twice by two users will still only count as one.

In order to figure out anonymous flagging, we'd need to develop this seriously. That is, IP Address recording, use of cookies or session, and "moving" those flags over when the user signs up for the site.

I was using the flag_content module

I think flag_content's flag is 'global'. Perhaps we could make our 'global' flags work for anonymous users too. But we certainly don't want an anonymous to be able to *unflag* a node.

Interestingly, different people see very different things when they see 'support anonymous users'. There's a feature request in views_bookmark's queue with at least four different interpretations on this.

Apparently Google's crawlers like to flag every node on my site...just a warning to anyone else who wants to try my method.

Just my $.02 about how I think "anonymous users should flag":

Case 0: Keeping Robots out!

For nice robots: use rel=nofollow in flag links. For misbehavers: uhmm... don't tell me we would have to CAPTCHA this! =|

Case 1: Flags that are per-user (like bookmarks), and current user is anonymous

• Admins decide if this is possible in Access Control
• First-time anonymous flaggers get a cookie for id-ing further flagging (ex: guest-12d97c761)
• Flags would be stored in a cookie or as temporary records in MySQL
• Ideally, if and when they decide to login (and/or create an account?) they can choose to transfer their flagged stuff into a "permanent" state. I guess if the cookie set above is present upon login, you can show a message using a hook_user() function, and clicking there would transfer the anonymous-flagged stuff.

Case 2: Flags that are global, and current user is anonymous

Not sure yet =)

I could usw the exact implementation that Moofie described:

I think flag_content's flag is 'global'. Perhaps we could make our 'global' flags work for anonymous users too. But we certainly don't want an anonymous to be able to *unflag* a node.

I would also like to see anonymous flagging be added

I second that request.

And yes, I agree.. Cookies can be a good way to go, if not just attaching to Drupal's already setup php session id. Also, to the maintainers, YES this an annoying aside for all those that do just fine flagging content for logged in users, but for how open and incredibly useful this project is, it's almost not fitting to the theme of the project to not include it.

Ah well.. turns out Session Favorites floats my current project just fine. Hopefully anyone else looking for this functionality will find this useful.

Maybe next year for the flag module ;)

Anonymous support for global flags:

This will happen. We're working on some issues (#322034, #285237, #160519) that will enable this.

Anonymous support for non-global flags:

This is tricky because of the Views support. Maybe database and/or Views trickery will help here.

http://drupal.org/project/lazyreg seems to fit for #5: Case 1
There's a patch for 5.x but 6.x seems delayed.

When I first installed this module, I navigated to /user/access, only to find out eventually that "Anonymous users may not flag content".

So yes, anonymous flagging would be great, please, for global and non-global flags.

I'm using this module to let guests flag a node [I like it or I didn't like it] they are all anonymous users... =/

+1 subscribe

I'm going to try to port lazyreg today; this seems like the ideal solution. If you have time to help, please email me or ping me in irc.

Could the Session API module be useful for an alternative approach? The Session Favourites module use it to store a favs list based on cookies and session ID. Session Favourites works for anonymous and authenticated users, but Flag has a more advanced interface, so porting this functionality to this module can be a valid alternative to lazyreg.

I attach a patch to the flag directory (6.x-1.0-beta6): it implements the Session ID provided by Session API module to distinguish one anonymous user from another, adding a new row into the database table named 'sid', filled with values provided by session_api_get_sid() (only this Session API function is used). It uses #1 method to allow anonymous users to flag content.

1. Disable and uninstall your current Flag installation
2. Download and install Session API
3. Unpack and install flag_anon.tar_.gz (or apply flag_anon.patch to Flag 6.x-1.0-beta6)

This method is an alternative to Lazy Registration proposed above: it implies some changes to the code apart these (which provides only basic functionalities), and this approach should be tested deeply, especially when a single authenticated user has multiple sessions opened: now a flags are assigned to a uid + sid couple, but if it causes problems on registered user this method could be used solely for anonymous users (uid = 0).

TODO:

• Add Session API to module requirements
• Change the approach for all code from "uid based" to "uid + sid" (User ID + Session ID)
• Test deeply!

Here the right patch.

(chirale, I haven't yet checked out your code, but I'm in favor of the idea. I see there's a demand for this feature and, a bonus, your patch seems small.)

Previous patches comes with an error on the first page visit by a user

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: SELECT * FROM flag_content WHERE content_type = 'node' AND content_id = 2 AND (uid = 0 OR uid = 0) AND sid =

since the Session ID (sid) is not assigned. This new patch solve this issue, using a fallback value (sid = 0, not assigned on session ID table) if sid is empty.

The query is executed to check whether a content is flagged or not, so an empty result for a new user is valid, but interaction with uid field should be tested deeply (since I use this function primary for anonymous users, any suggestion and improvement on this point is welcome).

Now a single logged-in user on two different browser can have two different flagged content, maybe this patch can be changed to use sid only for anonymous users, and uid for logged-in user. Even in this case, sid / uid interaction should be considered, since someone can ask to preserve the flagged content for an anonymous user that became a new user (after a registration or a log in).

Looks to me that queries like this:

Are likely to cause troubles for authenticated users. If a user logs in and flags, then log out, logs back in, then won't they get a different session ID? I haven't looked into Session API to see how such a situation is handled.

Feel free to actually remove the lines of code that are no longer needed rather than commenting them out, we'll still be able to see the changes in the patch file. Is there any way we can make this requirement optional, rather than hard-coded? That is, Flag would continue to work as-is for authenticated users, but when Session API is enabled, you get anonymous voting?

Great looking work so far! I'd be happy to get this into flag.

Thanks quicksketch. On this patch I've separated authenticated and anonymous users.

Anonymous users: uid = 0, session id (sid) assigned
Authenticated users: uid = current user ID, sid = 0 (not assigned)

On flag_content, table will be:

Where only uid or sid are filled (uid for authenticated, sid for anonymous). In the example there are three users, one authenticated (uid = 1) and two anonymous (session ID 2 and 5).

I've also added Session API as required module to install Flag on the info file.

Pending issues:

• If as anonymous user you flag some items and then login, you lose flagged content as anonymous. If you log out, content you've flagged as anonymous are lost (maybe session ID changes). Maybe it can be useful a merge on login (or registration) phase, altering, on user request, old anonymous user's flag_content rows (sid = 0, uid = just-logged-in user).
• Perhaps old session IDs rows should be deleted periodically if unused.

Please test on a new patched installation of Flags (uninstall the old one to delete db tables), since database structure changes can probably leads to weird errors on existing Flag data.

@chirale: Thank you for your work on this; this is a very exciting patch, and it seems like you're getting close :-))

When you said you added session_api to flag's dependencies, that gave me the idea to go ask the session_api developers to #360701: Port to 7.x and to create a core feature request: #360705: Add wrapper layer around authenticated and anonymous users so that they can be treated as one and the same. It seems like many modules will be able to learn from your patch here to make their functionality accessible to anonymous users.

I've also added Session API as required module to install Flag on the info file.

If possible I'd *really* like to make Session API optional, not required. Flag should be well written enough that we should be able to do this with only a few if (module_exists('session_api')) { calls. It's great news that authenticated users have a session id of 0 anyway, since that makes it so that we can easily enter a default value for authenticated users when Session API is not available.

At this time I've included it because there aren't these controls, and running the patch without that module causes a white screen. When these controls will be introduced, Session API can be switched to optional rather than required. If Session API is unavailable, however, #1 should be modified to block anonymous role selection on Flag admin screen, and a message referring to Session API to enable that role should be included there. Otherwise both sid and uid will be 0 for anonymous users.

Yep great. That was what I was expecting. Since we only need Session API for anonymous users, Flag should continue to operate as it does now for authenticated users, then if you have Session API it will enable use for anonymous.

Here's the new patch according to #25 requirements.

Looking good. Some more comments:
- Don't use tabs in the code, two spaces is standard for indentation.
- Always use brackets for IF statements, even if it's only one line.
- There's a call to session_api_available(), but if the module isn't enabled that's going to cause a function not found error.

We also might have to do a database update, as right now uid = 0 means that the node is flagged "globally" for all users. At the same time though, perhaps we can simply make uid/sid = 0 mean a global flag, since anonymous users should always have an SID.

"make uid/sid = 0 mean a global flag" seems to me the right solution, if we don't want to implement an additional "global" flag field.

I've worked out anonymous flagging for Drupal 5 based off the patch in comment #27. Its incomplete / broken and you can find out my problems (has to do with views) in my issue: #374278: Allow anonymous users to flag content (D5 backport).

This is the 6th version of the patch (made from 6.x-1.0-beta6). I've cleaned up the code according to #28 (I run code-style.pl, now it only complains that there are "mixed case function or variable names" errors on original code), introduced the flag_get_sid($account) (that call session_api_get_sid() where session_api is available) function and global flag support (sid = 0, uid = 0).

I've made several tests (without Flag actions enabled, please test it) and it works for global flags with and without anonymous flagging enabled, and with authenticated users and anonymous users with standard flag.

jrguitar21: nice to see a D5 version! Take a look to this patch, maybe it can be useful.

Nice! This looks pretty much ready to go to me! Views support even. Looks great. I've been thinking we need to end this "beta" business and make a stable release. However, I'd like to save this feature for 1.1 (especially considering we need to finish the D5 backport).

I looked at the code in #31, and it seems like it would work but correct me if im wrong in that the views display is going to require now an additional query (in the _is_flagged func) to check to see if a flag is flagged for a specified uid / sid pair?

so please correct me if im wrong but, is it like this?:

1) complex views query with lots of left joinage, and passing along the extra fields 'sid' and 'uid' for the ride into the 'handler' method

2) handler method uses those two fields, as well as the content_id (flag id) in the _is_flagged query to detect if its flagged for said user.

... guess I'm just a little confused, and my concerned for performance makes me ask why there has to be two queries to detect if its flagged or not.

UPDATE... D5 Backport

It looks like D6 has been functioning this way for a while with the necesity for additional queries in the $flag->is_flagged() stuff, so now I don't feel as bad for adding overhead. I backported that function to D5 and it fixed my problem. Have a look at comment #2 on the backport page i created for an updated and working patch for D5.

(@jrguitar21, the Views integration doesn't call $flag->is_flagged() (or $flag->_is_flagged()). In other words, no extra query is fired for each row.)

Could you please update the patch to work with rc1, and then with stable 1.0? :]

Thank you! :]

Szy.

Here's a reroll that works with the latest 6.x version.

This version adds an extra few lines to hook_user() to automatically transfer flaggings from an anonymous user to a logged-in user when the user logs in. Unfortunately this caused a few oddities with Session API, since the users session is changed when they log-in, and by the time hook_user is fired the global $_SESSION variable has already changed. To solve this problem I put a call to flag_set_sid() in hook_init(), so we set the user's Session API sid before the login process begins.

I also added a hook_update() to update existing databases.

This patch does not yet perform any sort of cleanup of old sessions from the flag_content table. I was trying to figure out how Session API usually does this, but its current API doesn't seem to be used by other modules. I've opened an issue over there to make some changes that would make its cleanup suitable for use with Flag. See #380550: Create a More Helpful Cleanup API. If that doesn't get approved, we might need to do our own kind of cleanup in a hook_cron().

Ah, and the patch.

Great! :]

Thank you, it's one of my most favourite modules.

Szy.

We want to integrate with http://drupal.org/project/visitor instead. We managed to get some experienced developers, webchick, jhedstrom (Session API), Eaton (Voting API), John VanDyk, and me to join forces on a unique API for handling "visitors" (anonymous and authenticated users) in Drupal. See #324743: Puzzle pieces for the intent and underlying concept.

Doh... well I guess it's a good thing we didn't add this to 1.0. Sounds like the maintainer of Session API is on board with merging with Visitor. At the same time it's disappointing that after acknowledging there were already 5 solutions we went ahead and made yet another one under the pretext that "this one will be better than those other ones". :P

I'm moving this to postponed while the dust settles. :(

Since the Session API code actually exists, maybe we can make flag_get_sid() adaptable on (existing) Session API and compatible with (oncoming maybe) Visitor? Developing a new module can require some months, so why we have to wait? Personally I like concept like Cache Router and WYSIWYG (the module, not the approach :-D), that let developers free to choose from different methods to do the same thing (caching or choose an editor).

Any progress?

subscribing

sorry, changed status unintended...

subscribing

Following the trail on this was fun...

It looks like this was paused to wait for the completion of the new visitor module (#39 above). Then looking at the visitor module, we see that the last cvs update was about 6 months ago, right about the same time that the visitor module was conceptualized in Puzzle Pieces.

It seems like there is plenty of interest in this feature, based on the number of people commenting on it. Is this still in the works? Does anyone know what the status is or what the current plans are for this update or the visitor module? Is there somewhere else to find more information about all of this aside from Puzzle Pieces, the visitor module page, and this page?

Yeah after all the hubbub about "Visitor" and the universal handling in core, I think the best approach is what we already have (#37 above). The other proposed approaches would require a full dependency on another contributed modules, versus this approach is "install only if you need it". Development has died down a little bit on Flag since we got a 1.0 out the door and the maintainers are both busy with other projects at the moment. Let's bump this back to needs work, get a reroll and start testing again.

That last tag I added should have been "anonymous flagging" (not "anonymous tagging"), but I mistyped and can't find how to edit the tag.

Looks like our last two comments came in at the same time and my status overwrote yours. Setting back to needs work re #47.

In general, if there are other issues that can be tagged anonymous flagging, that could help people keep abreast to our going consensus.

credit to fago for isssues tagged rules 1.0.

Fixing status.

great, the patch from #37 works fine with flag 6.x-1.0 btw. already using it on a productive site... ;)

Output of patch in #37

(aside: new component categories would be cool! this could be 'Provided module integration' instead of 'User interface')

will be awesome! subscribe

Bad to force the visitor to flag a node, keep it open, and add option to store what he flagged based on cookies & session.

subscribe!

I'm also using the patch from #37 in a production site. Thanks for the good work!

subscribe!!!

thanks for this! works great on my site. two aspects seem kind of unsolved: the cleanup of the session ids and the mass flagging by search engines. can I put a "nofollow" somewhere to at least keep out google?

working great against flag 6.x-1.1. I added this to robots.txt to prevent any false flagging:
Disallow: /flag/

This is working great for everything except global flags, when logging out all global flags i have set are unflagged.

Hope someone can help and this does work really well for non-global flags

Thanks

AlxM

Great feature that can be used for like-functionality on sites.

with the exception of global flags does anyone think this might make it as contributed into the module?

Hi Mike @ #1,

could you please explain a bit more as these lines dont correspond to anything relevant in the latest 6.x version. I can only assume the line to be edited to:
'#options' => user_roles(),
is @ 692 in file flag.module.

Your solution is good enough for me as I want global flags for anon users without intelligence. One flag as inappropriate should unpublish the content and inform moderators, so I dont really want to load the solution with SessionAPI etc.

Thanks

Mike replied in a PM and his line numbers from #1 are refering to the 5.x module and not 6.x.
Thanks for the clarification Mike

subscribing

I just applied the patch from #37 and the anonymous functionality appears to work great for the flag I have that needs the anonymous visitor support.

I am having an issue with another flag I have on the site that doesn't allow anonymous users to utilize. I think the issue I'm having is related to the patch from #37 because what I'm trying to do works on a different site with an unpatched version of Flag 6.x-1.1. Here are the details:

Flag1:
- global=no
- roles that may use this flag=anonymous users, authenticated users
- What nodes this flag may be used on: story

Flag2:
- global=no
- roles that may use this flag=content admin
- What nodes this flag my be used on: page

The idea for Flag2 is that the site's content admin users can Flag various pages around the site. Then, using Views, I'd like to create a block that lists all the Flag2 flagged pages for all visitors (including anonymous) to view. Relevant details about the view:

- Relationship: Flags: Flag2 by any user (include only flagged content by any user)

At this point, everything works great on the site that has the patched Flag module except for the fact that anonymous users don't see the Flag2 view (block). When I go into the flag/includes/flag_handler_relationships.inc file and comment out the code added by Patch #37:

The Flag2 view works as expected, but it breaks the anonymous user flagging capabilities. Perhaps this bit of code needs some sort of conditional around it?

I further confirmed the issue by creating the exact same Flag2 and View on a site with an unpatched version of Flag 6.x-1.1 and not seeing the issue.

Suggestions?

Thanks,
-mike

Thanks for the report mike, but this issue should stay as a feature request that "needs work", since it's not a bug Flag until it's been committed. Though it would definitely be good to correct this behavior and include the fix in the patch.

Nate,

Good point about the "category" - my bad.

Anyway, I believe I've fixed the issue by wrapping the relationship definition in a conditional to make sure the flag is available to anonymous users. If not, the relationship to the Session ID doesn't get included. It seems to have fixed the problem.

There's a chance that a similar fix needs to be made in the "includes/flag_handler_field_ops.inc" file, but I haven't had the time to think of a good test case for it.

I've re-rolled the patch against the latest -dev version of the module and attached it here.

-mike

Thanks, though rather than checking $user->roles against $flag->roles, we should just be using $flag->user_access($user), since Flag actually has a method just for this purpose. This makes it so that we could potentially have access granted on criteria other than roles.

Hmmmm... I'm not sure I follow you...

The code that I added simply checks to see if the particular Flag is available to anonymous users:

The check isn't dependent on a particular user's role, but on the roles assigned to a particular flag.

I'm not sure how a user_access($user) call will fit in here...

Also - I found a small bug in my previous patch file having to do with flag.install - I'll re-roll and post once we iron out this user_access() issue.

-mike

Oh, I'm not making much sense, sorry I saw role checking and immediately jumped conclusions without reading the rest of the code. Never mind, that's an excellent approach. :-)

Just to have one last whimper, maybe this would be a shorter way of saying it:
if (array_search(DRUPAL_ANONYMOUS_RID, $flag->roles) !== FALSE) {

Phew - thought I was missing something big.

Good point about the array_search() call - seems like every time I need to search an array, I implement it a little differently. Regardless, I made the change and the updated patch is attached.

Thanks,
-mike

I'm running this patch on a dev site and their is a major problem when page caching is turned on. Only the first user can flag, all other users will see the 'Bad token. You seem to have followed an invalid link.' message, simply because their session is different from the first time the page got cached. Not sure what the best approach is here to fix that.

Subscribing

subscribing.

+1 subscribe

Why not just use the the "Plus 1" Module with the Voting API? It has the following features:
1) AJAX
2) Extensive Views Support
3) Session based voting
4) Session time-throttling to prevent fradulent votes

The only two things that are lacking is:
1) If you wanted to add multiple types of flagging
2) Add actions after every flagging

Recent changes to Session API now persist the assigned sid across simple login/logout session changes, which should help out with this patch.

Subscribing. Does this patch need more testing ?

@macpuddin: you can't compare "Plus 1" to flag cause it's whole different module with different use case (even while sometimes it crosses with Flag)

Is it planned for these changes to be included in a proper release soon/at all?

This feature is planned for the 2.x version of Flag, though it's unclear how long it will take to implement this feature properly and get out a 2.0 version. There's a serious issue with listing flagged content in Views, as noted in #377396: Number of elements must be positive in /includes/database.inc on line 241 that should be fixed before this is committed.

Hi

I am trying to get this patch to work. I am using the stable version version on the drupal project page. I guess because the versions do not match with the diff patch, it isnt working.

Could anyone give me the right version to patch or even the patched version?

Thanks in advance.

Lukas

Hi again

Is there nobody to help me out?

Thanks

Lukas

Lukas, the current patch won't apply to any version of Flag. Even if it did, it's marked "needs work" because it does not work fully and I'd suggest avoiding trying to use it unless you intend to develop it further.

Hi quicksketch

So how are you developing if it is not working at all? What bugs are remaining? I could really need this...

Thanks

Lukas

No one is currently developing it, it needs to be manually updated and then developed from there. I've been working on the 2.0 version of Flag recently though so hopefully we'll come back to this soon, since it'd be the main feature and reason for a 2.0 version.

Current problems:
- The patch does not apply any more and needs updating to the 2.x code.
- Anonymous flagging does not work with the page cache enabled (As noted in #72).
- Anonymous flags do not show up properly in views (As noted in #80 and #65).
- Sessions need to be cleaned up on cron and nofollow needs to be added to links to prevent search-engine crawling (As noted in #57)

Here's a patch that is nearly ready for commit unless any further problems can be found.

- The patch does not apply any more and needs updating to the 2.x code.

Done, mostly just a few changes for the new $flag->access() method.

- Anonymous flagging does not work with the page cache enabled (As noted in #72).

Anonymous users are now given a less secure token than authenticated users, since they all need to have the same token when page caching is enabled. We've used a similar mechanism in Fivestar module for anonymous users.

- Anonymous flags do not show up properly in views (As noted in #80 and #65).

This problem seemed to have stemmed from always requiring a JOIN on the flag_content.sid (Session API ID) column even if it wasn't necessary. This JOIN is now only added if showing a page that is limiting the flagged content to the anonymous user's content exclusively. Additionally I disabled the anonymous user page cache when displaying a list of content flagged by anonymous users so that an anonymous users "My bookmarks" page will work as expected. Views that show flagged content by all users (anonymous and authenticated) are not affected by this change to the page cache.

- Sessions need to be cleaned up on cron and nofollow needs to be added to links to prevent search-engine crawling (As noted in #57)

Session API created hook_session_api_cleanup in the 1.1 version, which is now implemented by Flag to clean up expired IDs.

Between this patch and #335453: Import/Export Support, this completes all the functionality I'd like to include in the 2.0 version of Flag, so the sooner this is reviewed the sooner we can put out a new alpha/beta for the 2.0 version.

I wrote the current patch again the 1.1 version of Session API, though the APIs have changed in the 1.2 version which has not yet been released (see #589800: Release 1.2 version). This patch should work with either version of the module by making an adjustment to flag_session_api_cleanup().

This version also implements a change to hook_requirements() which recommends /flag/ be added to the site's robots.txt file to prevent search engines from randomly flagging/unflagging content on the site.

So this patch applied to Flag 6.x-2.x-dev coupled with version Session API 1.1 solves all the bugs listed in #86? Will the next Flag 2.x developement snapshot implement these changes? I like to try the latest version, especially if solves the troubles with cache.

I think that a Flag 2.x + Session API 1.2 (released on October 5th) is the right choice, but 1.2 support should be confirmed to proceed with an extensive testing, because 1.1 support is discontinued. Thanks.

Thanks for putting this together. I applied the patch and enable Sessions API 1.1. I didn't notice any up front errors, and each flag-settings page now does have checkboxes for anonymous users, but when I check those boxes and save the new settings, anonymous users are still not able to flag posts. The flag links simply don't appear for anonymous users. Is there anything special I need to do beyond enabling Session API and checking those boxes?

This version of the patch now works for "global" flags. I can no longer find any problems with this version of the patch. Note that you need to run update.php after applying the patch. If you've already run update.php from a previous version of the patch, then you should re-install flag or start from a previous database. The flag_update_6201() function ended up being used by #489610: Add index to 'count' in flag_count table, so if you run update.php again you'll likely receive database errors.

Unless there are huge bugs in this version, I'll probably commit to the 2.x branch to make testing easier. After this it's clear sailing to a 2.0 beta. :-)

Ah, also regarding the significant increase in file size... this version adds quite a bit of JavaScript to show the correct flag state for anonymous users when the page cache is enabled. Anonymous user pages are always output the same regardless of the user's flags, then flag.js checks the user's cookies and updates the state to match.

Well, let's put it into CVS and see if dev users can dig up any problems. Committed to the 2.x branch! Thanks chirale and ultimike for the persistence and all the rerolls. Since this issue is already nearly pushing nearly 100 comments, please open a new issue for any problems with the anonymous flagging system.

Automatically closed -- issue fixed for 2 weeks with no activity.