Closed (outdated)
Project:
Rate
Version:
7.x-1.6
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
30 Jan 2013 at 16:45 UTC
Updated:
18 Sep 2025 at 13:25 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
murat_halici commentedHere's a patch.
Comment #2
sazcurrain commentedHi,
You don't need a patch for this, because the function ip_address() already solved it.
You just have to tell to Drupal that you're behind a proxy, setting the variable reverse_proxy to true. Just add this configuration to your settings.php file.
Check out the implementation of ip_address() here http://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/ip_ad... for more information.
Hope it helps.
Comment #3
murat_halici commentedI tried adding $conf['reverse_proxy'] = TRUE; in the settings.php file before creating this issue, but it didn't work for me because the IP address of our ELB is not static.
Comment #4
sazcurrain commentedOk, you're right. ip_address will give you the wrong ip in that conditions.
I have a similar problem, but inverse, where anonymous users behind a unique public ip (like in any LAN) where considered the same.
But instead of patching Rate, i choose to make a new module overriden the storage hooks provided in Voting API to include the session id in the source of the votes.
the code looks like this:
For this to work, you just need to set de variable 'votingapi_storage_module' to MY_MODULE. You can do it manually in the setting.php, but i prefer to include it in MY_MODULE.install, so you can set/unset de variable when installing/uninstalling the module.
The advantage of doing it this way is that you can update Rate and Voting API without loosing your changes.
Comment #5
murat_halici commentedThat seems like an excellent solution and I will definitely give it a shot. Thank you very much for sharing!
Comment #6
murat_halici commentedIs your custom module for D7, because I'm getting a NULL value in that votingapi_vote table for $_COOKIE["session_api_session"].
This is what I get when I print kpr($_COOKIE);
.. (Array, 2 elements)
SESS92a88ee34743fb4c539744fcb181c39c (String, 43 characters ) qxi53L3Dbz8xQsaC1eerdEPad47KSNHI8ZhHVLuDxFY
has_js (String, 1 characters ) 1
I tried using session_api_get_sid() which I found in http://drupal.org/node/319656 but that didn't seem to work either.
Comment #7
sazcurrain commentedYes, you're right again, if there's no sessions started, that code will fail.
I didn't notice this error until I clean up the cookies and cache.
Thank you very much for finding this bug in my code! luckly for me, i didn't have it in production yet.
Unfortunately, i can't find a workaround to this issue yet. I tried to call session_get_sid(TRUE) before reading the cookie, but it didn't work as I expected.
session_get_sid() should create a new session when called for the first time, but i have to refresh the page 3 times for the value in the cookie to be available.
I'll keep working in a solution to this issue.
Comment #8
sazcurrain commentedWell, I belive I got a solution, but i feels a bit "artificial" to me.
The root problem is how Session API checks if the browser accepts cookies.
It checks if the $_COOKIE variable is set, if not it assumes that's because the browser don't accept cookies. But if you just clean your browser cache, session api will jump to a wrong conclusion and prevent the creation of the session, until another module creates a least one cookie.
So, to solve this problem you just have to create a dummy cookie before the call to session_api_get_sid().
The second problem is that after you call session_api_get_sid() for the first time, the variable $_COOKIE['session_api_session'] isn't available right away. It takes another refresh of the browser to get the value of this varibale.
The way i found to workaround this issue is to read the session id from the databse intstead of the cookies, only the first time.
I moved the code to alter de source of a vote to a new function, to avoid repeating it.
Right now, this is working for me with an anonymous user in a browser with a clean cache, but I'll apreciate all the feedback that i can get (two testers are better than one :) )
Thank you!
Comment #9
sazcurrain commentedSorry, false alarm. This is still not working.
I had a piece of session_api.module commented and forgot about it, that's why it was working. :(
I'll keep trying...
Comment #10
sazcurrain commentedOk, the thing with the php's set_cookie function is that it don't affect de variable $_COOKIE right away. It always takes a refresh of delay for the variable to reflect the changes.
So, the only solution is to create the cookie and set the adecuate value in $_COOKIE at the same time.
So, the code for MY_MODULE_alter_vote_source ends looking like this:
Now this work, but it still feels very very artificial. I hope it was a better way, but i don't see how without patching session api.
Comment #11
dmegatool commentedJust wanted say that sazcurrain solution seems to be working for me too. I needed to allow people under the same IP to vote anonymously. Here at the office, we're all able to vote even being using the same public IP. Thanks man !
Was a pain to gather the code parts in 53 different messages so here it is all in one place ready to be copy/pasted. I commented the dpm($vote['vote_source']); line. It was throwing me an error as Devel ain't installed.
MY_MODULE.install
MY_MODULE.module
Comment #12
Solthun commentedThe cookie implementation here is pretty great, but for the original topic of the issue, the first comments solved the issue completely.
I my case hosting was on AWS and the following 2 lines solved the voting issues I had with anonymous users:
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array($_SERVER['REMOTE_ADDR']);
Comment #13
jamieonkeys commentedHere’s a version of @dmegatool and @sazcurrain’s code which works with Drupal 10 (and probably 8+). I used Claude to write it but it’s working fine on an actual project. The full module code, with comments, is at GitHub.
Comment #14
ivnishDrupal 7 is EOL. Issue will be closed, but patches are still here