Welcome, Guest!!
follow us on... rss

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Mike

Pages: [1] 2 3 ... 20
I think your server must not actually be sending the query to us....the "Error: No return data from API query" tells me the query is probably not making it to our server or you'd be getting something back.

There's a section in the BotScout.php file like this:

Code: [Select]
// Use file_get_contents
$returned_data = file_get_contents($apiquery);
$ch = curl_init($apiquery);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$returned_data = curl_exec($ch);

This bit determines whether the query is sent via file_get_contents() or via curl. It may be that your PHP config has a restriction on file_get_contents() or curl.

You could mod the code to force one or the other, but you might also want to look at the php.ini file or the output of phpinfo() to see if there are any restrictions imposed on either of those two functions.

As near as I can tell you're doing everything right at this point- the user email and IP are being put into the query correctly (not sure where the user name went, but that's not important at this point).

Can you check with your ISP and see if they can tell whether or not there are any restrictions on file_get_contents() or curl?

How do I use the "standard query" not XML?

I did everything but that step and submitted and got this:

Code: [Select]
UserName: krasnhello
UserEmail: krasnhello@mail.ru
Test String: http://botscout.com/test/?multi&mail=krasnhello%40mail.ru&ip=
Error: No return data from API query.

Okay, try this...

1) First, change these lines in your BotScout.php file:

Code: [Select]
   // create your own custom form fields here
   // see documentation for more information
   $XUSER = $_POST['user_name'];
   $XMAIL = $_POST['user_email'];

Code: [Select]
   // create your own custom form fields here
   // see documentation for more information
   $XUSER = $user_name;
   $XMAIL = $user_email;

2) Then, find this section  in the registration.php file and make it look like this:

Code: [Select]
if (!$error) {
    $additional_field_sql = "";
    $additional_value_sql = "";
    if (!empty($additional_user_fields)) {
      $table_fields = $site_db->get_table_fields(USERS_TABLE);
      foreach ($additional_user_fields as $key => $val) {
        if (isset($HTTP_POST_VARS[$key]) && isset($table_fields[$key])) {
          $additional_field_sql .= ", $key";
          $additional_value_sql .= ", '".un_htmlspecialchars(trim($HTTP_POST_VARS[$key]))."'";
   // add this line
   print "FORM VAUES: UserID: $user_id<br>UserLevel: $user_level<br>UserName: $user_name<br>UserEmail: $user_email <br>";

   // call the botscout file...
   // BotScout.com "BotBuster" check

// quit here so we don't pollute the user table

    // (marker, these don't get changed)
    $activationkey = get_random_key(USERS_TABLE, get_user_table_field("", $user_table_fields['user_activationkey']));
    $user_id = $site_db->get_next_id($user_table_fields['user_id'], USERS_TABLE);

3) Turn on diagnostic output in the BotScout file, use the standard query to us (not XML), and try to register. Use a known bad name and email when you register:

name: krasnhello
email: krasnhello@mail.ru

...and let's see what gets printed out. :)

A return message of "Error: No return data from API query" means you're not getting any data sent back from us, and that's a problem. You should get something sent back that starts off, "API Data: (returned data)".

The only reasons I can think of for that happening is that maybe curl isn't configured correctly on the server or maybe it has some outgoing restriction on it. (??)

This registration page submits to itself - would that make a difference? For example, when you go to the registration page you are on register.php.
When you click "Agree" you are still on register.php.
When you submit your info you are still on register.php

Submitting to the same page is very common and shouldn't be a problem.

The key things are 1) that the user name and email variables be populated and 2) that the BotScout.php file is called as soon as they're available (populated). And, of course, that this be done just before the submitted form fields are processed by the registration code.

Form fields filled out --> Form Submitted --> Botscout intercepts fields --> (accept or reject) --> Form fields processed

Either way - thanks for the help. If it can't be done with this script - I'll have to accept that. :)

We've never found a form that BotScout couldn't be made to work on. From SMF to Wordpress to Joomla to VBulletin and so on, it can be made to work on any form.

Contact forms and registration forms basically work the same way (taking in some fields and submitting them for processing) so I'm sure there's a way to make it work with your form as well.

Would it be possible to send me the whole registration PHP code file?

Code: [Select]
Test String: http://botscout.com/test/?multi&mail=MYEMAIL&ip=MY IP&key=MY KEY
Error: No return data from API query.

I'd have to review the code- I'm not sure if the "ERROR" indication means that something went wrong or not. It may just mean nothing way found, but according to the API docs it should always return something...hmmm.

Let us know what happens. You may also want to do a test registration just to make sure it's not blocking registrations for some reason.

Okay here's what I think comes next:

1) Find a place in the submitted portion of the form code where the username and useremail values do print out whatever was entered into the form. This will ensure that the variables are available to the botscout code. 

2) Place the call to the botscout.php file immediately after that (or as close after it as feasible).

3) Also, instead of include(ROOT_PATH.'BotScout.php');, try using a require statement:


Using require will force the code to halt if for some reason it's not actually finding the BotScout.php file, whereas include will not.

Finally, add a print/exit statement to the botscout.php code to verify it's actually being called and is running.

If you add the diagnostic line right after the last extracted variable (as shown below) and then try to register, do you see the user name and email printed out?
Code: [Select]
  $user_name = (isset($HTTP_POST_VARS['user_name'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_name'])) : "";
  $user_name = preg_replace("/( ){2,}/", " ", $user_name);
  $user_password = (isset($HTTP_POST_VARS['user_password'])) ? trim($HTTP_POST_VARS['user_password']) : "";
  $user_email = (isset($HTTP_POST_VARS['user_email'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_email'])) : "";
  $user_showemail = (isset($HTTP_POST_VARS['user_showemail'])) ? intval($HTTP_POST_VARS['user_showemail']) : 0;
  $user_allowemails = (isset($HTTP_POST_VARS['user_allowemails'])) ? intval($HTTP_POST_VARS['user_allowemails']) : 1;
  $user_invisible = (isset($HTTP_POST_VARS['user_invisible'])) ? intval($HTTP_POST_VARS['user_invisible']) : 0;
  $user_homepage = (isset($HTTP_POST_VARS['user_homepage'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_homepage'])) : "";
  $user_icq = (isset($HTTP_POST_VARS['user_icq'])) ? ((intval(trim($HTTP_POST_VARS['user_icq']))) ? intval(trim($HTTP_POST_VARS['user_icq'])) : "") : "";

print "username: $user_name, usermail: $user_email"; exit;

The code should halt at this point, printing out something like: username: (somevalue), usermail: (somevalue)

Does it halt and/or print anything out when you add that code and then try to register?

Typos, typos....try this instead:

Code: [Select]
print "username: $user_name, usermail: $user_email"; exit;
Also, I'm not sure about this, but this might be the place to put the call to the botscout.php file:
Code: [Select]
  $user_name = (isset($HTTP_POST_VARS['user_name'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_name'])) : "";
  $user_name = preg_replace("/( ){2,}/", " ", $user_name);
  $user_password = (isset($HTTP_POST_VARS['user_password'])) ? trim($HTTP_POST_VARS['user_password']) : "";
  $user_email = (isset($HTTP_POST_VARS['user_email'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_email'])) : "";
  $user_showemail = (isset($HTTP_POST_VARS['user_showemail'])) ? intval($HTTP_POST_VARS['user_showemail']) : 0;
  $user_allowemails = (isset($HTTP_POST_VARS['user_allowemails'])) ? intval($HTTP_POST_VARS['user_allowemails']) : 1;
  $user_invisible = (isset($HTTP_POST_VARS['user_invisible'])) ? intval($HTTP_POST_VARS['user_invisible']) : 0;
  $user_homepage = (isset($HTTP_POST_VARS['user_homepage'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_homepage'])) : "";
  $user_icq = (isset($HTTP_POST_VARS['user_icq'])) ? ((intval(trim($HTTP_POST_VARS['user_icq']))) ? intval(trim($HTTP_POST_VARS['user_icq'])) : "") : "";

// BotScout.com "BotBuster" check

  $captcha = (isset($HTTP_POST_VARS['captcha'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['captcha'])) : "";


I'm not familiar with the 4images code, but are you certain that the variables are accessible at the point where you've added the call to the BotScout.php file?

It's possible that in or after this section:

Code: [Select]
if (!empty($additional_user_fields)) {
      foreach ($additional_user_fields as $key => $val) {
        if (isset($HTTP_POST_VARS[$key]) && intval($val[2]) == 1 && trim($HTTP_POST_VARS[$key]) == "") {
          $error = 1;
          $field_error = preg_replace("/".$site_template->start."field_name".$site_template->end."/siU", str_replace(":", "", $val[0]), $lang['field_required']);
          $msg .= (($msg != "") ? "<br />" : "").$field_error;

....you may need to explicitly extract the user_name and user_email vars from the $HTTP_POST_VARS array so they can be 'seen'.

As a test you could add something like this to the reg page just before the call to the BotScout.php file and then do a test registration to see if the variables are printed out:

Code: [Select]
print "username: $user_name, usermail: $user_email; exit;"

BotScout Discussion / Confabulation Error #xxxxxx
« on: November 14, 2015, 10:57:04 AM »
We get a fair number of emails that say something like this: "Help, when I run the Raw PHP sample code for querying the API, its shows me a 'Confabulation Error' message."

The "Confabulation Error" response in the default code is simply a placeholder for what your code should do as a response an API query run against our database.

In other words, this is where you will need to put some code to handle the response we return indicating that a suspect record was found in our database (depending on the type of query you send, i.e. IP address, email address, etc).

You should really only need to use the raw code if you're developing your own plugin or implementing the BotScout API in a form or internal process that doesn't already have an existing plugin.

BotScout Discussion / FireHOL - firehol_level1
« on: September 11, 2015, 07:26:47 AM »
FireHOL is a project that combines several IP blacklists in order to create a more comprehensive list with (hopefully) fewer false positives.

About firehol_level1
This IP list is a composition of other IP list

The objective is to create a blacklist that can be safe enough to be used on all systems, with a firewall, to block access entirely, from and to its listed IPs.

The key prerequisite for this cause, is to have no false positives. All IPs listed should be bad and should be blocked, without exceptions.

To accomplish this, we include the following IP lists:

    fullbogons - the unroutable IPs
    spamhaus drop and edrop - Don't Route Or Peer IPs
    dshield - the top 20 attacking class-C
    malware lists - the Command and Control IPs

firehol_level1 is updated automatically every time any of its IP lists is updated. If you use FireHOL's update-ipsets.sh, you can just enable it and it will be composed directly from the individual lists, on your computer. Otherwise, you can download it from github.


BotScout Discussion / Re: BotScout module for Drupal
« on: July 02, 2015, 02:33:12 PM »
Outstanding work, Acetolyne, thank you!

BotScout Discussion / Joomla users: jHackGuard Issues and Problems
« on: December 26, 2014, 10:55:20 AM »
You probably came to this page because you're using the jHackGuard plugin and are suddenly unable to access your site or login to it.


Entienda por favor: NO te estn bloqueando.
Ju lutem kuptoni: Ne nuk po bllokojm JU.
Խնդրում ենք հասկանալ ՄԵՆՔ ՉԵՆՔ ԱՐԳԵԼԱՓԱԿՈՒՄԸ ձեզ.
Mesedez ulertzeko: EZ duzu gara blokeatuz.
Калі ласка, зразумейце,: Мы не блакуе вас.
Molimo razumijem: Nismo blokirate.
Pochopte prosm: Jsme neblokuje VS.
Se il vous plat comprendre: NOUS NE SOMMES PAS VOUS blocage.
Bitte haben Sie Verstndnis: Wir sind nicht Sie blockiert.
कृपया समझते हैं: हम आपको अवरुद्ध नहीं कर रहे।
Vi preghiamo di comprendere: NON ti stanno bloccando.
Jekk jogħġbok jifhmu: WE ARE MHUX IBBLOKKAR INTI.
Proszę zrozumieć: my nie blokując dostęp.
Vă rugăm să nțelegeți: nu te blocheaza.
Пожалуйста, поймите,: Мы не блокирует вас.
Ni mste frst: VI R INTE blockerar dig.
Будь ласка, зрозумійте,: Ми не блокує вас.
Vennligst forst: Vi er ikke blokkerer deg.
Παρακαλούμε να κατανοήσετε: δεν είμαστε ΜΠΛΟΚ ΣΑΣ.

Be aware that the jHackGuard plugin has been found to have serious problems:

1) Upon installation it may lock users and admins out of the site, and

2) it returns an erroneous message when the site using it runs out of daily queries. This causes ALL registrations and logins to fail.

When this happens the plugin blocks ALL users and erroneously points them here to BotScout as the source of the problem.

If you've installed jHackGuard and are now having problems with your site, it's not us. It's the plugin.

Unfortunately, since we didn't write the plugin there's nothing we can do to resolve this problem.

Some users have been able to edit the Joomla database to bypass it and allow it to be uninstalled, others have had to resort to restoring the site from a backup.

Until the author corrects the plugin's behavior, you might want to uninstall it and/or use a different plugin.

One last thing- we'd really appreciate it if people would contact the author about this issue. You can do that here:



The BotScout Team

BotScout Discussion / BotScout for WordPress
« on: August 14, 2014, 03:25:42 PM »
Thanks to Jimmy from JimmysCode.com, a new plugin for screening comment spam in WordPress is now available:


Direct link at WordPress.org: BotScout Comment Protection

BotScout Discussion / BotScout and Cloudflare
« on: May 10, 2014, 10:14:40 AM »
A user sent in this note regarding using BotScout with Cloudflare:

To work behind cloudflare your general code needs to be updated as follows:

Code: [Select]
// get the IP address


For those who aren't familiar with Cloudflare, this is a description of their service:

"CloudFlare protects and accelerates any website online. Once your website is a part of the CloudFlare community, its web traffic is routed through our intelligent global network. We automatically optimize the delivery of your web pages so your visitors get the fastest page load times and best performance. We also block threats and limit abusive bots and crawlers from wasting your bandwidth and server resources. The result: CloudFlare-powered websites see a significant improvement in performance and a decrease in spam and other attacks."

BotScout Discussion / Re: Bots that just register not being caught?
« on: March 13, 2014, 07:05:55 AM »
We already do this. :)

I'm thinking there could be some "registration honeypots".  Heck, all I would have to do is to turn on self-registration on my site and disable all links to that page, and that's a honeypot.

Basically, set up something that looks like a real site but real people have no reason to register an account there.  The bots have profiles of every kind of site that can handle posts or comments, so they'll find the registration page and do their thing.  So, every single registration is a bot.

In fact, I'm a little surprised this sort of thing doesn't already exist.  The registrations alone from those bots are a problem, even if they can't post spam.

Pages: [1] 2 3 ... 20