Needs review
Project:
User Referral
Version:
7.x-1.0-beta4
Component:
Code: referral
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Apr 2010 at 14:38 UTC
Updated:
26 Nov 2016 at 14:31 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
kbahey commentedThe proper way is to set the $base_url in the settings.php for the site.
Comment #2
josepvalls commentedThere are modules that overwrite the $base_url parameter in order to enable sites to serve content from both http and https.
I.e. My user profiles (editing) are sent in HTTPS, therefore the $base_url is https://www... but the public profiles are sent in HTTP.
I can't tell you exactly how I came to this (currently I have secure pages disabled) but take a look at:
http://drupal.org/node/61099
http://crackingdrupal.com/blog/greggles/drupal-and-ssl-multiple-recipes-...
http://success.grownupgeek.com/index.php/2009/07/12/drupal-ssl/
http://drupal.org/node/629578
http://drupal.org/project/securepages
Comment #3
chadhester commentedI just ran into this as well. I set my $base_url value and the issue went away. It might be a better idea, however, to add an administrative configuration value to force HTTP or HTTPS for all the referral links.
Comment #4
IRuslan commentedI'm also had this problem, but in my case because referral code was different on http://www.example.com and http://example.com pages, or on site which uses other sub-domains.
Why module creator rely on $base_url?
Comment #5
josepvalls commentedMy guess is to obfuscate the tokens. Use a string of your own or set your base url.
If the developer doesn't see the need on replacing it I think this can be closed.
Comment #6
jrust commentedUsing base_url definitely makes this module incompatible with secure_pages(). secure_pages has this code:
Moreover, as the function name, _referral_hex_seed(), implies the point is to provide some security so that referral urls can't be spoofed. However, given that this code is all open source this really provides no security as anyone can look at the code for this module and figure out the encryption scheme. One option is to get rid of this additional security, the other is to have the module use a random unique seed that it generates upon installation. Given that this causes the module to not work for sites that use https or have multiple subdomains it seems a major bug.
The attached patch makes it an admin setting. It maintains backwards compatibility by setting the variable to a substring of $base_url, but for new installations sets it to a random string.
Comment #7
jrust commentedComment #8
ArtActivator.com commentedAnd not only incompatible with securepages!!!!
Also with languguage subdomains!!!
I switched all users to SSL and now I lost 1500 referrals, because after switching to ssl, it also about 1600 referrals registered!
Very bad idea........... :(
---------------------------
www.ArtActivator.com - Order your success
Comment #9
kaizerking commentedI am also looking for this fix for 7.x-
Comment #10
socialnicheguru commentedUpdated the patch for Drupal 7. Please test