The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Hello
i have a fresh version oft drupal 8 and the http:BL Module.
But after i type in the Key and enable it the Webside is down with:
"The website encountered an unexpected error. Please try again later."
"Comment submissions only. (Blocked comments are unpublished, regardless of comment moderation permissions.)"
That Option i have enable.
Update:
When i run drupal in a subdomain the Modul works fine.
Can it be well it runs in a folder /drupal7/testdrupal8/.
That Drupal 7 Blocks it ?
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | Fix_IPv6-2931626-12.patch | 2.58 KB | bryrock |
| #6 | Drupal Fehler.png | 34.12 KB | rothlive |
| #6 | Drupal Fehler 2.png | 58.71 KB | rothlive |
Comments
Comment #2
rothlive commentedHello
i have a fresh version oft drupal 8 and the http:BL Module.
But after i type in the Key and enable it the Webside is down with:
"The website encountered an unexpected error. Please try again later."
"Comment submissions only. (Blocked comments are unpublished, regardless of comment moderation permissions.)"
That Option i have enable.
Comment #3
rothlive commentedComment #4
cilefen commented"The website encountered an unexpected error. Please try again later."
When this happens something is logged. Check the logs.
Comment #5
bryrock commentedThanks for the information. Not going to be able to look at this for at least 2-3 weeks.
Comment #6
rothlive commentedI searched a little longer because on one server it didn't work on another.
It's a problem with Ip 6 addresses. If you switch off IP 6 everything works.
Something about the database and the data type.
Below the PHP error message.
AH01071: Got error 'PHP message: Drupal\\Core\\Entity\\EntityStorageException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'host_ip' at row 1: INSERT INTO {httpbl_host} (uuid, host_ip, host_status, source, expire, created, changed) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array\n(\n [:db_insert_placeholder_0] => \n [:db_insert_placeholder_1] => Deleted IP 6\n [:db_insert_placeholder_2] => 0\n [:db_insert_placeholder_3] => Project Honeypot\n [:db_insert_placeholder_4] => \n [:db_insert_placeholder_5] => \n [:db_insert_placeholder_6] => \n)\n in /drupal-8.4.3/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php on line 805 #0 ..\n'Comment #7
bryrock commentedI honestly don't a see a specific enough issue being reported here, though the IPv6 possibility is a good theory, because, yes, httpbl storage is not large enough for IPv6 addresses.
I don't understand the update regarding using the module in a drupal7 folder(?).
Another possible issue is the conflict with page_cache. For more info see #2868126: TypeError: Argument 1 passed to Drupal\Core\Routing\RequestContext::fromRequest() must be an instance.
The workaround for that one is to use only dynamic_page_cache with httpbl.
The dev release has recently been updated to fix an unreported issue that only affected adding/editing IPs manually using the form.
As long as page_cache is not enabled, httpbl is working with Drupal 8.5.6.
Comment #8
bryrock commentedReduced priority from Critical.
Comment #9
darren ohI have confirmed that the issue is that the host_ip column is limited to 15 characters. This prevents users with IPv6 addresses from using the site. I was able to use my site after changing the character limit for the host_ip column to 39. The core ban_ip table uses a limit of 40 characters, so that should be the limit for consistency.
Comment #10
bryrock commentedThe httpBL service itself (at Project Honeypot) does not support IPv6.
You'll never get a positive hit on an IPv6 IP, so all IPv6 hosts will appear as "safe."
Comment #11
darren ohIt’s better for IPv6 addresses to be assumed to be safe than for them not to be able to use the site at all.
Comment #12
bryrock commentedAs long as Project Honeypot doesn't support IPv6, then I agree there's nothing that can be done other than to assume IPv6 hosts are safe (or uninstall the module, of course), but I don't see any point in actually storing them as "safe." Seems dishonest.
So here's another approach:
The IP is validated for IPv4. If it's not, then a $project_supported (FALSE) variable is sent to the evaluator function [evaluateVisitor($ip, $request, $project_supported)].
When that function sees it's not a supported query, it marks it "safe", logs a notice (that it won't actually be checked) and returns the request without any further lookups, local or Project Honeypot.
The IP still gets through, but no checking is done and no storage happens, so no crash.
Comment #13
darren ohI have reviewed the patch and successfully tested it on my own site.
Comment #14
darren ohChanging the field length to accommodate IPv6 addresses could still be helpful for addresses that an admin adds manually.
Comment #16
bryrock commented