Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

Why not call reports directly through URL instead of using xlib_jasperreports.show_report? #48

  • replies 3
  • views 485
  • likes 0

Sure, you can do it. But it is less secure. For public reports this could be fine.
Typically, in an enterprise context, you would want to control access to your reports and data.

Thus, you want to be able to identify a user (authentication) and then control whether this user has access to the report (authorization).

This can easily be done with APEX, conditions and pl/sql. Thus, I recommend using a separate Tomcat which is hidden from the outside world through firewalls and only accessible from the DB server. This way you can control everything nicely.


Pardon me, I am a bit confused. What does xlib_jasperreports.show_report have to do with security? As far as I am concerned, it's job is to form the URL. It has nothing to do with security, right?
The security part as you mentioned can be done using APEX, conditions, PL/SQL, firewall, etc... .
If that's the case, then why the need to xlib_jasperreports.show_report in the first place?


Well, xlib_jasperreports.show_report() will form the URL AND execute the report through the database backend using UTL_HTTP. Thus, the call to the Tomcat (where jri.war resides) is done from the database, NOT the client browser.

So, basically, the database works as a proxy for the request. Thus, you can implement security restrictions inside of the proxy, so to speak.

When you don't do it this way, everybody who gets a hold of the syntax for calling the report, can call the report. I.e. the report and datasource becomes publicly available.

That is the difference. There is no security integration implemented in the jri.warJ2EE application. When you know the url and the names of the data sources ... you have public access.