When I first installed Spambot, it wouldn't work as I was sitting behind a proxy.
I thought other people might have the same problem, so I wrote a patch to overcome the issue.
What this patch does:
- provide a section on the Spambot admin page to specify the details for the proxy server (address, plus username/password if needed)
- if a proxy address is given, instead of performing the request to stopforumspam.com using drupal_http_request, I rewrite the request using CURL using the proxy settings.
What this patch doesn't do:
- allow the "Report to stopforumspam.com" to go through the proxy. I don't have an API key to try it, and I was too lazy to do it as well... If I have more time later, I might try to have a go at it. But if someone has an API key at stopforumspam.com and some spare time, it should be as easy copying the code I've already added and tweaking slightly the response to get something similar than what drupal_http_request returns.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | spambot-behind_proxy-1272302-7.patch | 3.89 KB | tlaurent |
| spambot_proxy.patch | 4.01 KB | tlaurent |
Comments
Comment #1
bengtan commentedHi,
Hmmm ... wouldn't it be cleaner (and more efficient) to make the SFS server address (ie. stopforumspam.com) configurable? Then it would work for all communications.
And if you configure a transparent network proxy in your upstream network, it's just a drop-in replacement. Possibly no need for username and password either.
Furthermore, why not use drupal_http_request() instead of curl? I know some people like curl and they automatically use it out of habit, but if it's not really needed, why add another dependency?
Comment #2
tlaurent commentedHi bengtan,
I'm not quite sure I understood everything you said...
drupal_http_request() doesn't work behind a proxy (there's been talks for years to change it to handle proxy, but they're still talking about it for Drupal 8), that's why I use curl, because this allows me to specify the proxy settings in my request.
"if you configure a transparent network proxy in your upstream network": I'm not sure I quite get it, but I guess what you recommend is to change the proxy setup. The problem is that in a lot of places (like where I work), you don't have any control over it, this is handled by Systems Administrators, and they are very "rigid" with the way they set up things.
About the first sentence in your reply, could you let me know what changes I'd need to make to the url to force it to go through the proxy ? Something like prefixing the url with the proxy address ? If this was possible, I agree it'd be the best solution.
I'm sorry, but my knowledge about it is fairly limited...
Comment #3
bengtan commentedHi,
My apologies. There are many different types and implementations of proxies, and when I first read your original post, I just thought of a transparent proxy ie. something that just forwards http requests to the web transparently.
After reading up some more on proxies, it's evident this is not your scenario.
However, I also came across:
#7881: Add support to drupal_http_request() for proxy servers (http not https)
#735420: Drupal 6 proxy server support
and they are working on a cleaner and more effective solution which will fix this issue for all of core instead of just for a single (or a few) use cases.
I think that's a better approach. Can you not patch from those issue(s) until the feature finally hits Drupal core? I don't really want to be adding a new feature that will later become obsolete.
Comment #4
tlaurent commentedHi,
Thanks for that.
I should have been more specific about the type of proxy. It is indeed not a transparent proxy but a web proxy acting as a layer between our web servers and the net.
I've already seen the threads you mentioned, and I have to admit I was a bit reluctant to patch core with some patches which are flagged as not passing SimpleTest. After a closer look, it looks like the patches are working and not passing SimpleTest because of a problem of version number, so I might give it a try.
For the matter of not including the patch into the main release, that's perfectly fine and I completely agree with you. When I released the patch, it wasn't really for you add it in the main release, but to allow other people with the same problem than mine to use this great module.
I think it'd be a shame for people not to be able to use such a useful module only because they have a proxy problem, so I just wanted to provide an easy solution to tackle it.
Maybe it wasn't a good idea from me to label it as "Feature request", but I couldn't see a more appropriate category.
Comment #5
bengtan commentedHi,
Actually, the patch for D6 from #735420: Drupal 6 proxy server support is quite simple. Besides the admin forms for configuration, the actual functionality is just a few lines change in drupal_http_request(). So, if you have a decent developer around, and some formalised source/site control procedures, it's not a tricky patch to maintain yourself.
I'm a bit reluctant to implement this feature in spambot.module, but I'm happy to have this issue remain open for other people to find. If that's satisfactory for you, it's also satisfactory for me.
Comment #6
tlaurent commented"I'm a bit reluctant to implement this feature in spambot.module, but I'm happy to have this issue remain open for other people to find. If that's satisfactory for you, it's also satisfactory for me."
Yes, that's perfectly fine for me.
Oh, I forgot to thank you for this module. It's clever, well written and very very useful. Thanks for that !
Comment #7
tlaurent commentedRewritting the patch to be compatible with Git patching.
Comment #8
bengtan commentedIt looks like proxy server support for drupal_http_request() was added in Drupal 7.17. See #7881: Add support to drupal_http_request() for proxy servers (http not https) approximately comment 444, so this is a non-issue for Drupal 7.x.
I will leave this issue around whilst Drupal 6.x is still supported.
Comment #9
kala4ek