Page 1 of 1
probable bug: ABE only works most of the time
Posted: Fri Aug 23, 2013 7:14 am
by niobos
Hi,
I've been debugging some pieces of code for over 3 hours now, so my mind is a bit of a mess. Apologies if this post also becomes a mess.
I have 2 webservers. One has a public address, the other is in the RFC1918-range (10.x.x.x). I load up an HTML-page from the public server, which wants to do a POST (standard application/x-www-form-urlencoded, so a "simple request") to the internal one. However, It didn't work most of the time, but sometimes it did. I later figured out that it was NoScript filtering out the requests because of the ABE rules. I have several issues:
- GREAT JOB! I don't want public webservers to be able to post to internal ones!! Thanks for that! I DO want it to happen in this particular case though...
- Sometimes it DOES work... I think it's a bug somewhere. Not particularly often, but like 3 out of 50 tries. How should I proceed to pinpoint this?
- It would have saved me like 2 hours of debugging had NoScript given an indication that it was blocking the request. All I got was "error", without any explanation... Consider this a feature request.
For reference: this fails:
Code: Select all
$.ajax({
type: 'POST',
url: 'http://dns.that.resolves.to.internal.ip/test.php',
crossDomain: true,
data: {
'some': 'data'
},
success: function(msg) {
console.log(msg);
},
error: function(jqXHR, textStatus, errorThrown){
console.log(textStatus);
console.log(errorThrown);
}
});
and so does test-cors.org
Re: probable bug: ABE only works most of the time
Posted: Sat Aug 24, 2013 3:41 am
by Thrawn
niobos wrote:
GREAT JOB! I don't want public webservers to be able to post to internal ones!! Thanks for that! I DO want it to happen in this particular case though...
Would you like help writing an exception rule? It would need to go in your SYSTEM ruleset, above the existing rule, and it would look something like:
Code: Select all
Site dns.that.resolves.to.internal.ip
Accept from dns.that.resolves.to.external.ip
# built-in rule
Site LOCAL
Accept from LOCAL
Deny
If it still doesn't work, you could try including the IP addresses as well as the hostnames.
Sometimes it DOES work... I think it's a bug somewhere. Not particularly often, but like 3 out of 50 tries. How should I proceed to pinpoint this?
Hmm...it depends on what ABE detects (and when) as a local address. Giorgio would have to be the one to answer that.
It would have saved me like 2 hours of debugging had NoScript given an indication that it was blocking the request. All I got was "error", without any explanation... Consider this a feature request.
Well, you would have been spamming the Messages tab of the Error Console (Ctrl+Shift+J)...
ABE will give you an alert if it blocks the top-level page that you're loading, but not always if it blocks a third-party site.
Re: probable bug: ABE only works most of the time
Posted: Sat Aug 24, 2013 7:23 am
by niobos
Thrawn wrote:niobos wrote:
GREAT JOB! I don't want public webservers to be able to post to internal ones!! Thanks for that! I DO want it to happen in this particular case though...
Would you like help writing an exception rule? It would need to go in your SYSTEM ruleset, above the existing rule, and it would look something like:
Thanks for the offer, but not at this point. My main complaint was that it took me longer than it should have to figure out NoScript was responsible for blocking my request (whether this was the expected behavior or not is less relevant for this point)
Thrawn wrote:
Well, you would have been spamming the Messages tab of the Error Console (Ctrl+Shift+J)...
ABE will give you an alert if it blocks the top-level page that you're loading, but not always if it blocks a third-party site.
OK, I see your point...
What about returning a error which is a little more descriptive in the XHR-object? (Although I'm not sure that a plugin can do that)
Right nog I only get "error" without any pointers as to why. I have been reading up on CORS for hours, and couldn't find anything wrong with my response-headers. Until I figured out with tcpdump that the request wasn't even made...
Re: probable bug: ABE only works most of the time
Posted: Sat Aug 24, 2013 9:35 am
by Thrawn
niobos wrote:Thrawn wrote:
Would you like help writing an exception rule? It would need to go in your SYSTEM ruleset, above the existing rule, and it would look something like:
Thanks for the offer, but not at this point. My main complaint was that it took me longer than it should have to figure out NoScript was responsible for blocking my request (whether this was the expected behavior or not is less relevant for this point)
Yeah, ABE does not have the friendliest interface. I'm actually working on that in a separate extension - although at present I'm focusing more on providing a simple way to write rules, rather than improving the feedback.
Thrawn wrote:
Well, you would have been spamming the Messages tab of the Error Console (Ctrl+Shift+J)...
ABE will give you an alert if it blocks the top-level page that you're loading, but not always if it blocks a third-party site.
OK, I see your point...
What about returning a error which is a little more descriptive in the XHR-object? (Although I'm not sure that a plugin can do that)
Right nog I only get "error" without any pointers as to why. I have been reading up on CORS for hours, and couldn't find anything wrong with my response-headers. Until I figured out with tcpdump that the request wasn't even made...
Gotta love hard-to-trace bugs.
I wonder whether it would be worth having a 'noisy' option (or keyword?) for ABE, to make its notifications more intrusive? They certainly are easy to miss; you shouldn't have to routinely check the Error Console, especially not the Messages tab, without some other indication that something is wrong.
Re: probable bug: ABE only works most of the time
Posted: Mon Oct 07, 2013 8:32 am
by niobos
Thrawn wrote:I wonder whether it would be worth having a 'noisy' option (or keyword?) for ABE, to make its notifications more intrusive? They certainly are easy to miss; you shouldn't have to routinely check the Error Console, especially not the Messages tab, without some other indication that something is wrong.
I would already be glad if the error console/messages would show that ABE blocked something. The only way I found out that it was the ABE, was by sheer chance. A noisy option would help when debugging rules, but not with figuring out what is actually causing the problem.
So to re-formulate my feature request: Have ABE report to the console when something is filtered. Just like I get a 404-error reported to the console.