It is obviously important that web applications keep technical errors from appearing in the user interface. The first thing that "white hat hackers" do is try and cause errors, to see if the application will give out information ( file paths, IP addresses, etc. ).<br />
<br />
To call a BIRT report we put the name of the report in the URL ( when calling /frameset... ). So, tweak the file name in the URL and you get an error back that gives the path to the reports on the server. Ouch. Severity #1 security issue.<br />
<br />
I've tried writing a servlet filter to catch this condition and stop it from going back to the UI - failure<br />
I've tried changing the source of the HTMLReportEmitter.java class and commenting out the 'outputErrors' call - also a failure<br />
<br />
Of course, I can use JavaScript or CSS to 'hide' the error from the UI, but the error text still came back to the browser, and the hacker/security dude can see it. <br />
<br />
<strong class='bbc'>I can't find a real solution!</strong><br />
<br />
It really surprises me that the BIRT team hasn't put something in place to turn off detailed error messages. I like BIRT. I have lots of respect for what they've built. But this is really bad. Unless, of course, this was a design decision they made so that you have to step up to a paid product if you really want to use BIRT in production applications. If that's the case....they've successfully scr%
@#ed me and I'm not liking them so much anymore. Either way, not cool.<br />
<br />
Has anyone fixed this?<br />
<br />
Brandon