Jump to content
JasperReports Library 7.0 is now available ×

Force Domain Security / Prevent Changes on Accident


Recommended Posts

Dear all,

we are currently setting up our Jasper Server and I came across a few question. I could not find any answers on the forum:

1. I see that I can securty my domains but how do I secure my topics? I understand some may be created from domains so they will be fine but what about those created from JRXML's?
2. I understand the concept of domain security but in our case this may not be sufficient. Reports should always be filtered according to SITES. Now if someone from another department (organization admin) modifies a domain and creates a new join tree how can I prevent that or make him to create a security file? Even when creating a new domain, how can I guarantee that the filter will be applied is this somehow possible?
3. Related to 2. I am adding attributes to my user profiles. I see that the value column is limited to 255 characters this may not be sufficient for us. I think the best would be to add multiple attributed with a suffix and then adjust the groovy expression. Is that how you would do it?



Link to comment
Share on other sites

  • Replies 4
  • Created
  • Last Reply

Top Posters In This Topic

I'll take a shot at this...

1.  There is no built in way to add security to topics that are not built on domains.  This is one of the main benefits of using a domain.  If the reports/topcs created in Jaspersoft Studio or iReport are done so using domains, then the security of the domain will apply to the report/topic.

2.  The only way I can think of to manage this would be by creating a custom datasource that requires the SITE as defined in a user profile attribute and catch it at that level.  Our professional services team has created things like this for customers who need a datasource that goes runs queries against a different DB based on the organization passed in, so I am confident something like this is possible.

3.  I am not entirely clear on what you are proposing.  My first reaction is that you may want to log your use case in the tracker to justify the need for a larger profile attribute column and see if an enhancement can be made.  In the mean time, doing some level of mapping of short name/value attributes would be in order.

I hope this helps.


Link to comment
Share on other sites

Thanks for the reply!


Thanks for 1 and 2. I will look at the option with the custom datasource. Sounds that this could be helpful.


To explain 3. Our sites are identified by a uuid which is 32 characters or something. So one user can only store like 3 sites in one attribute. Now my idea was not to go with:


sites: 435345345345345v...,34545...,345345


rather doing:


site1: 345435345...

site2: 267465654...

site3: 342354545...


Thanks again.



Link to comment
Share on other sites

I though about this a litle bit more and played around with the custom datasource. You are right I could react on a missing site attrbiute of a user. But what I can not do there is to make sure that the domain was configured correctly. So even if a user has a site attribute set the domain could have been defined without a security file.

Could I also create a custom datasource that ALWAYS applies a where condition to any SQL?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...