Active
Project:
http:BL
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
20 May 2015 at 23:16 UTC
Updated:
27 Aug 2018 at 19:47 UTC
Jump to comment: Most recent
I'm running several language subdomains on a site, and honeypot requires having a different script for each subdomain. I laid this out in more detail in...
http://www.projecthoneypot.org/board/read.php?f=6&i=890&t=890#reply_971
... and got confirmation that this is a must.
Drupal lets you run the same site under different domains/subdomains for any number of reasons, and httpbl should allow entering an unlimited number of domain+honeypotlink pairs.
Comments
Comment #1
salvisLet me explain this in some more detail and propose a solution:
For a multi-language site we can have domains like
--www.example.com
--en.example.com
--de.example.com
which all point to the same site. ProjectHoneypot requires registering three different sites and gives you a different script for each of them. However, http:BL takes only a single Honeypot link and puts that in the footer of all three sites.
Another example is, if you install the Domain Access module, then you can run any number of completely independent domains in the same Drupal installation and give each one completely different content. Yet, http:BL allows only one single Honeypot link.
I propose the following solution:
Currently you're storing this information in the 'httpbl_link', and 'httpbl_word' variables. Store this in
--httpbl_link_www.example.com and httpbl_word_www.example.com
--httpbl_link_en.example.com and httpbl_word_en.example.com
--httpbl_link_de.example.com and httpbl_word_de.example.com
instead.
Rather than creating a complicated form just add the following text (using the current hostname)...
... and store the input in the corresponding variables. And use the right version when populating the footer, depending on the current host name.
I haven't been able to find out what Project Honeypot does when the wrong script is executed, but it might make sense to not populate the footer if the hostname does not match. Maybe write a warning to the watchdog log.
Would you accept a patch following this strategy if I write one?
Comment #2
bryrock commentedSorry it has taken me nearly two years to reply to this. I've just recently ported this module to D8, and want to look into adding this feature. I won't yet promise to back-port it to D7, but will definitely consider it, especially if you send a patch. D8 version is in my head now, and radically different from D7, though not so much for the config form itself, except, yes, variable handling is all new.
In the meantime, do you happen to have any copy of the forum thread you linked to at project honeypot? I know that in the past month they just went through a weeks long maintenance period, and since the site has been back the old forums appear to be absent (in short, the link in your post no longer works).
Comment #3
salvisToo bad that the message board has disappeared. I haven't been able to find my post anywhere, but there's probably not much more than in #1, except that they confirmed specifically that matching the full hostname exactly is a must for the honeypot to work.
I'm very challenged for time with a lot of D8 porting work still ahead of me, so I won't be able to come up with a patch anytime soon.
Comment #4
bryrock commentedComment #5
salvisThe message board has come back:
https://www.projecthoneypot.org/board/read.php?f=6&i=890&t=890#reply_971
Comment #6
salvis