[TAC] Fool Bot Honey Pot [Paid] 3.0.32

[HWS]

So what you are saying is that it is 100% impossible for him to add the feature back once it is corrected on the other add-on?

+ you even could do it yourself.

 

[Brent W]

+ you even could do it yourself.

I don't get why you are replying to me like this. I tagged him so he could fix it and improve his add-on. Whether or not I can do it on my own isn't the point.

 

[tenants]

Actually, I've left the code in... you only need to uncomment it and change the method to public / protected
- I don't want to be in a situation where some users have old versions of the blog and it should work as "public" and other have an updated versions with "protected" so it's simpler to leave it commented out (people expect it to just work without worrying about versions of other plugins)


On another note, if anyone ever thinks they have a bot that gets through FBHP I would be very very interested (This has never been shown to be the case)

If you could
1) Send me the user details from the FoolBotHoneyPot logs. If it is not there, it did not register via the registration form / registered before you installed FBHP, in which case, it did not get past FBHP - That I'm not so much interested in (try using StopHumanSpam and a CAPTCHA in your facebook-other registration mechanism)
2) If you could let me know why you think it's a bot, such as "spamming 100 messages within just a few minutes"

- Any information would be very important to me

I've worked in automation for a while, and I would be surprised if
1) This mechanism was even targeted
2) It was bypassed with automation (It would be quite tricky to do)
It's not impossible, but very unlikely (especially without a script engine)

I quote myself that "FBHP currently stop 100% of spam bots registering" and I still stand by this, a day may come where this is no longer true, and if it does I need to be alerted about any early warning signs

I say this, since someone mentioned they had a bot get through FBHP... this I doubt very much (and have no evidence to suggest this) but appeal to anyone that thinks this has happened to send me information.. let me know in this thread (censoring email addresses / password log details)

The only spam you might get once you have FBHP installed is human spam (in which case, use StopHumanSpam), or old bots that registered before FBHP was installed (StopHumanSpam should also stop this)

 

[DRE]

I get this error when using the latest paid versions of TAC and FBHP. I installed it manually uploaded to the server etc.

 

[tenants]

@DRE can you tick the option in FBHP to use: Legacy Mode (as a test), I suspect you will still have this issue, it doesn not happen with FBHP (alone or with other add-ons that override actionRegister correctly)

Nothing has change from previous versions, have you installed another add-on that might affect the registration area.

It sounds like something is overriding the actionRegister and not allowing other add-ons to use this area (not passing through the parent values)

If other add-ons override and do not pass through the parent, they can break all other add-ons that use the same area.

If you can search through your files (I use agent ransack, but you can probably use a windows search for this), search though all your xenforo plugin files that contain the text " public function actionRegister" ... let me know what they are, and I can probably identify the offending addon for you (if they're free / public)

... I'm a bit drunk after a few hoegaardens, so sorry if I'm not completely coherent... it is a weekend night after all

 

[DRE]

Dang I already uninstalled it. The only other registration addon I have enabled is the new version of Mandatory Location by @ceribik

 

[tenants]

Yup that's the one cocking things up.. they use actionRegister() and don't pass through the parent, so that will balls up every add-on that uses actionRegister() with an order that is lower than it's self...
Even with my beer goggles I can see that
~

I can tell you what to add to fix it, it' not really your job to though

I also understand why the addon developer might do it, it's not easy to extend actionRegister, since as soon as you call the parent, you allow the user to be created (unless you have returned within your override). The first time I extended it, I also duplicated this function, but it's a greedy thing to do that will break all other add-ons

Just do this, to this file:

librbary/MandatoryLocation/ControllerPublic/MandatoryLocation.php

find the function

public function actionRegister()

at the very end, where it says
return $this->_completeRegistration($user);

instead replace that text with this:
return parent::actionRegister();

(since the parent will call the overridden _completeRegistration anyway, and calling the parent will allow other add-ons to run that use this area, and then they too can call their versions of actionRegister.. allowing this add-on to be compatible with other addons as FBHP and many other addons are)

 

[ceribik]

instead replace that text with this:
return parent::actionRegister();

(since the parent will call the overridden _completeRegistration anyway, and calling the parent will allow other add-ons to run that use this area)

Yeah it was my first addon which I wrote a couple years ago when there weren't any other hacky plugins that messed with the registration forum. I might consider doing something similar to what you did, which would avoid the duplicated code (assuming I can get it to work).

Speaking of which, given that my addon is currently duplicates the original registration function, wouldn't calling " return parent::actionRegister();" cause issues with registration, or would that not be an issue since _completeRegistration() is not being called?

 

[tenants]

@ceribik
Yeah, you'll want to take out this too "$writer->save();" and allow the core parent to do make the actual save, egh.. extending actionRegister is messy

calling parent::actionRegister(); at the end allows plugins to be called that extend this function (in the acp defined executions order), then I think the parent

http://xenforo.com/community/threads/my-add-on-causes-a-security-error.49384/#post-528822
http://xenforo.com/community/thread...-likely-with-xenforo.11172/page-4#post-422732

I should have a look at your code when I'm more sober, if you don't add anything extra with the datawriter, then you should be fine in just allowing the parent to do the actual save (in calling the parent, you can then also take out some of the duplicate code)

 

[webroxau]

I don't appear to be getting ANY logs for FBHP now. Just have "No errors have been logged." on the
FoolBotHoneyPot Logs page.

I have the option ticked for Log events and Log Passed events.

 

[tenants]

I don't appear to be getting ANY logs for FBHP now. Just have "No errors have been logged." on the
FoolBotHoneyPot Logs page.

I have the option ticked for Log events and Log Passed events.

Roughly how many were you getting a day before, and how long have you waited. You will certainly have less logged now, since both the cache and session will prevent known bots

Can you send me a screenshot of your options and private message me your forum URL and I will try to reproduce with your configuration

 

[tenants]

@graham_w Having had a brief look at your site, I'm going to have a guess that you are also using Mandatory Location by @ceribik

This plugin will currently stop any add-on from working that tries to make use of the actionRegister, since it is not passing through and returning the parent (see above comments)

I think @ceribik is currently looking in to it

... I would turn it off if using in combination with any other add-on that makes use of actionRegister

It's likely the addon Mandatory Location is not currently compatible with

• FoolBotHoneyPot
• Sonnb StopSpamHere
• StopCountrySpam
  
• Automatic Watch Thread and Watch Forum on Registration
• XenUtiles
• multiple account detection tools
• Register Email
• CustomImgCaptcha
• Others Addons that I don't know about

- I believe all of these use actionRegister. However, the above should be compatible with each other, since they all return the parent

@ceribik which hacky plugins were you talking about, I haven't run into any that don't return the parent yet.

 

[ceribik]

Dang I already uninstalled it. The only other registration addon I have enabled is the new version of Mandatory Location by @ceribik

Ok this should be fixed now on my end (addon). The only change I made was the one @tenants suggested (wasn't able to do what I hoping), and so it might be easier to just make the change yourself.

 

[Mouth]

This plugin will currently stop any add-on from working that tries to make use of the actionRegister, since it is not passing through and returning the parent (see above comments)

http://xenforo.com/community/threads/alter-ego-detector.60972/page-7#post-747571 is the same issue?

 

[tenants]

http://xenforo.com/community/threads/alter-ego-detector.60972/page-7#post-747571 is the same issue?

Yes, but it shouldn't be public, pre_dispatch should always be protected

.. so that was my fault in an earlier release (that bug should never have gone out), which I then went through and made sure they are all protected
.. try the latest version

 

[webroxau]

@graham_w Having had a brief look at your site, I'm going to have a guess that you are also using Mandatory Location by @ceribik

This plugin will currently stop any add-on from working that tries to make use of the actionRegister, since it is not passing through and returning the parent (see above comments)

You were right, I didn't even read the few posts prior. If I had I would have figured it out. My apologies for wasting your time. All is working now and getting the bot rejection logs as expected. Not getting the repeat bot hits like before which is great, but still 90+ in 12 hours

 

[shawn]

Is the proxy detection affected by reverse proxies on our web server? I have noticed that the legitimate new users all show use of proxies in the logs. Seems unlikely that this would be the case.

 

[tenants]

Are they real proxies, or suspected proxies in the FBHP logs?

For Transparent Proxies (Logged as: Proxy Headers Found)
If you server is adding a proxy to the header, then all users will look like they are using proxy according to any type of transparent detection, since it is present in the header
(some web servers do add proxies to the header)... don't worry, this is just logged information, proxies are not prevented by FBHP (StopCountrySpam has the ability to stop proxies)


For Suspected Proxies (Logged as: Possibly Forged IP Address)
A lot of legitimate users will have something that looks "like" a proxy
... This isn't uncommon for ISPs, but FBHP never blocks these types of proxies, it just logs the information.

Basically, the information is there to support evidence (you might also notice, bots never use anything in their user-agent that identifies them as a bot.. this is almost always faked to look like a browser)

However, ISPs will often fall into one of these:

ReverseDNSIP != ipAddress
Or
ipAddress == ReverseDNS


But, often when you reveal the reverseDNSIP you reveal the host, and this can give a lot of spam information away (just google the host)

FBHP also detects other transparent proxies in the header, but most bots & humans never use these (and sometimes real humans can without even realising).

Basically, a lot of bots will fake these to look like they are not using a proxy
And a lot of ISP will often trigger the ReverseDNS situations...
So, we never block users based on proxy... the information is only logged, fbhp avoids false positives, proxy detection is not a good method of judging if something will be spam or not

 

[shawn]

Are they real proxies, or suspected proxies in the FBHP logs?

For Transparent Proxies (Logged as: Proxy Headers Found)
If you server is adding a proxy to the header, then all users will look like they are using proxy according to any type of transparent detection, since it is present in the header
(some web servers do add proxies to the header)... don't worry, this is just logged information, proxies are not prevented by FBHP (StopCountrySpam has the ability to stop proxies)

Correct, they all say "$_SERVER[HTTP_X_FORWARDED_FOR]: xxx.xxx.xxx.xxx", which I'm 99% sure is getting added to the headers by my front-facing web server.

 

[tenants]

I've seen some web-servers add this, but the information is correct... If your web-server is adding it, all users that visit your site do now have the "HTTP_X_FORWARDED_FOR" add to the header.

It's only logged by FBHP, and could be added if going through a load balancer / proxy service