Force Domain Security / Prevent Changes on Accident

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?

Thanks

ke

kolja.ehlers@iconplc.com's picture
Joined: Aug 12 2008 - 2:47am
Last seen: 5 years 11 months ago

2 Answers:

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.

Thanks!

mgeise's picture
44353
Joined: Mar 5 2007 - 6:18am
Last seen: 3 years 3 months ago

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.

kolja.ehlers@iconplc.com - 10 years 1 month ago

your solution for #3 should work...just a matter of parsing the values out for your needs. In fact, if your query ends up with something like Where ABC IN (123,456,789), your format may work to your advantage.

mgeise - 10 years 4 weeks ago

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?

kolja.ehlers@iconplc.com's picture
Joined: Aug 12 2008 - 2:47am
Last seen: 5 years 11 months ago
Feedback
randomness