Posted by chrism2671 on October 13, 2008 at 4:44pm
Jump to:
| Project: | Advanced Poll |
| Version: | 5.x-1.0-beta6 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
| Issue tags: | Advanced Poll, AdvPoll, anonymous user vote, poll, vote results, votingapi_vote |
Issue Summary
Which permission does this? I couldn't get it to work,although I'm sure it's trivial.
Thanks,
Chris.
Comments
#1
I'm interested in figuring this out, too. No luck so far...
#2
Still not got a solution for this. If anybody does, please let me know!
#3
Check this thread in VotingAPI issues: http://drupal.org/node/108341
After applying the patch in I got rid of this problem:
http://drupal.org/node/108341#comment-819121
The patch doesn't seems not to be included in latest available VotingAPI 5.x-1.6 release.
However, now I'm getting error message from advpoll/modes/binary.inc during vote cancel, if anonymous users are allowed to cancel their voters.
#4
Please don't say you're getting an error message without reporting what the message is. How does that help anyone?
#5
I'm having the same problem with 6.x (but don't see any error messages, sadly :)
#6
Sorry about that, I didn't have enough time to check this in details until now. When using the patched VotingAPI as described in #3 in order to allow anonymous users to vote (and also because my host is behind reverse proxy) I'm getting following error message when anonymous user tries to cancel the vote, and the vote is not deleted from the database:
warning: Invalid argument supplied for foreach() in /sites/all/modules/advpoll/modes/binary.inc on line 315.
The patched VotingAPI module uses
$_SERVER['REMOTE_ADDR'].'-'.$_SERVER['HTTP_X_FORWARDED_FOR']for the hostname for anonymous users, while in function advpoll_cancel only HTTP_X_FORWARDED_FOR is used. That probably explains why the vote doesn't get deleted from votingapi table in database, because the hostnames don't match.
EDIT:
I quickly fixed these by changing in file advpoll.module function advpoll_cancel, line 1345
$host = $_SERVER['HTTP_X_FORWARDED_FOR']? $_SERVER['HTTP_X_FORWARDED_FOR'] : $_SERVER['REMOTE_ADDR'];to:
$host = $_SERVER['REMOTE_ADDR'] . ($_SERVER['HTTP_X_FORWARDED_FOR'] ? '-'. $_SERVER['HTTP_X_FORWARDED_FOR'] : '');And replaced line 1341
if ($user->uid && count($user_vote = votingapi_get_user_votes('advpoll', $node->nid)) > 0) {with:
$user_vote = votingapi_get_user_votes('advpoll', $node->nid);if ($user->uid && count($user_vote) > 0) {
I think the $user_vote was not set anymore after the if-else block, when it was used. It seems that these modifications cleared the error message & anonymous cancel problem. Unfortunately I'm unable to produce a patch file for these right now.
However, I think that there may be an issue with the patched VotingAPI, since the patch does not address the problem with function votingapi_get_user_votes (which also advpoll_cancel calls), which will return all votes where userid 0, not checking the hostname.
#7
It looks to me like there's an issue with the _advpoll_user_voted() function which may be related to this. When this function tries to work out if the current user has voted yet or not the logic runs like this:
IF logged in
$voted = votingapi_get_user_votes()
IF ($voted) $cancel_vote = true
IF !$cancel_vote
manually fetch votes for this hostname from votingapi_vote table, set $voted = true if any found, set $cancel_vote = true if vote was anonymous
IMO this is bad logic. Firstly it's possible for a logged in user to not have voted, and therefore not warrant a $cancel_vote option, in which case the second IF block will fire; at this stage, if anyone has voted on the poll from the same hostname, $voted will be set true. Also, if an anonymous user has voted from the same hostname, they will be given the $cancel_vote option.
The other problem with this comes in the case where an anonymous user is trying to vote from the same IP as a registered user. They're not logged in, so the first block fails and the second block is triggered; again, if anyone has voted on the poll from the same hostname, $voted will be set true.
I think these would be addressed by (a) changing the
if (!$cancel_vote)into anelse, and adding anAND uid = 0to the SELECT query. Oh, and make the$_SERVER['REMOTE_ADDR'] . ($_SERVER['HTTP_X_FORWARDED_FOR'] ? '-'. $_SERVER['HTTP_X_FORWARDED_FOR'] : '')change mentioned above as well. I'll give it a try and see...#8
It may be a slightly different problem but the symptoms were nearly the same.
note: I used the patch as stated above and working with the binary poll.
I'm using the CAPTCHA module and I noticed that it was stuffing extra info into the database at
votingapi_vote -> hostname.
The hostname field was set to varchar(128) and changing that to varchar(256) gave more room for the info that the cookie contained.
It now shows the results correctly for Anonymous (UID-0) from the same IP using the patch's cookie setting.
I wouldn't suggest changing the field type if you've any votes, I'm neither a PHP or MySQL coder. I only noticed the lack of available space in the value because it was truncated. If my change to the table was a bad idea, I would really like to know!