mgeise

SummaryError setting up report when applying Column-Level Security ... or the java error, NullPointerException. After Setting up Column-Level Security, when you run a report, you can encounter an "error setting up report" and NullPointerException like below. Symptoms CausesInvalid Case: a report is already created with some columns concerned by new Column-Level security rules. When a user X try to run this report, if a security rule denies acces to some columns for user X, the above error message is returned. Resolutions This is not a bug, just an Invalid Case. Create your security rules first and then users concerned by those rules can create their own reports. If you modify those rules in the Domain Security File, be sure to modify also your concerned users' reports, or tell them to recreate theirs.

JasperReports Server Pro v3.5 ships with these Ad Hoc chart types: BarPieLineAreaScatterTime SeriesPointsProblem: for some reason you want to hide a chart type from the end users. Solution: Short answer: all you need to do is comment out the type in the static block of ChartStateDelegate.java static { chartTypes.add(ChartViewModel.BAR_CHART); chartTypes.add(ChartViewModel.PIE_CHART); chartTypes.add(ChartViewModel.LINE_CHART); chartTypes.add(ChartViewModel.AREA_CHART); chartTypes.add(ChartViewModel.SCATTER_CHART); //chartTypes.add(ChartViewModel.TIME_SERIES_CHART); } Long answer: Look at jasperserver-warsrcmainwebappWEB-INFadhocactionModel_ChartViewModel.xml The menu option for the chart type picker is defined here ChartViewModel.getTypeDisplayMap() refers to the map of all chart types which is in turn defined in ChartStateDelegate.java in this line: protected static List chartTypes;

This article serves as an informative example on setting up JasperServer to authenticate through a central authentication system, namely CAS. Note:This example is not intended to work with your specific implementation of CAS or the specific version of JasperServer that you are using, but is intended to allow you to follow along and make the necessary changes to your own implementation to acheive the same result. This example will only work with JasperServer versions prior to v3.5: Please see the Authentication Cookbook for the most recent information and examples. Setting up a CAS Server for TestingJA-SIG provides a CAS server packaged as a web application, and it comes with a built-in authentication module that is suitable for testing. The built in authentication module will accept ANY username/password combination where the username and password are the same. (so "barry/barry" works, but "barry/berry" fails.) You can download the server from the JA-SIG download page. I highly recommend you look at the Server Deployment section of their site. It contains a ton of useful information, a deployment guide, and the indispensible "Solving SSL Issues" pages. As described in the "CAS Design And Implementation" section, the CAS validation service only accepts requests using a secure transport. This means that you must have a valid certificate on your CAS server machine, and your CAS client must be configured to trust that certificate. There are two important points to keep in mind 95% of all "it doesn't work" problems are caused by the improper use of certificates. (The single most common failure is that the hostname in the server's certificate doesn't match the actual host name.)Test with the CAS server on a separate machine (virtual machines are OK).To create a certificate for the server you will need to use the Java keytool command. keytool -genkey -alias tomcat -keyalg RSA -validity 365 -keystore some-file-name You will be prompted for a bunch of information, two of which are critical. When prompted for "Your first and last name" you must put in the hostname of the system. When asked for the keystore password use "changeit" since that is what tomcat uses by default. You need to modify $CATALINA_HOME/conf/server.xml on the app server running CAS to use your certificate. Find the commented out section on setting up a secure HTTPS connector and follow it. Restart tomcat and test that it accepts https connections. CAS gives a ticket to our server after the login page, and we have to pass that ticket to the CAS server to validate it and convert it to a user name. The CAS specification requires this connection to be over HTTPS for security. Since its being called from Java instead of the browser, the Sun security system kicks in. If it doesn't get a certificate that it trusts, it won't connect. There are two things that have to be right in order for the security system to trust the certificate. First, It has to have been told to trust the signing certificate and secondly the host name has to match the host name in the URL. The first is fairly easy. Copy the file you used as the keystore to the machine the client web application is running on, and add "-Djavax.net.ssl.trustStore=" to the invocation of the Java VM. This is typically done by adding it to the JAVA_OPTS section of the catalina.sh (or catalina.bat on Windows) file in $CATALINA_HOME/bin. A sample catalina.sh file is attached to this page. To get the hostname in the certificate right you have to make sure you network is configured correctly so you can use the hostname that matches the one in the certificate. I found out the hard way that Sun's code rejects IP addresses that match for some odd reason, forcing you to use a name. Configuring JasperServer to use CASAcegi security has a CAS authentication provider, so we use it to support CAS from JasperServer. JasperServer has contained the required helper class (com.jaspersoft.jasperserver.api.metadata.user.service.impl.UserDetailsServiceImpl) since the 2.0.1 release. You need to make a bunch of edits to applicationContext-security.xml to use CAS. I've attached a ApplicationContext-security.zip that, in complete violation of recommendations above, uses the same machine for both the web app and the CAS server. (Search for "BK" in the file to find all the section modified. Two were added, and one block was commented out.) Using a remote CAS server just involves changing the casValidate URL and the loginURL. The first change is to the authenticationManager bean. Make the providers list contain a reference to a local bean named "casAuthenticationProvider" and our existing "anonymousAuthenticationProvider". All other providers should be removed. The list should look like: <bean class="org.acegisecurity.providers.ProviderManager" id="authenticationManager"> <property name="providers"> <list> <ref local="casAuthenticationProvider" /> <ref local="anonymousAuthenticationProvider" /> </list> </property></bean> We also need to make sure that the URL called by the CAS server with our ticket isn't handled as a normal user request. Modify the finterChainProxy bean to look like: <bean class="org.acegisecurity.util.FilterChainProxy" id="filterChainProxy"> <property name="filterInvocationDefinitionSource"> <value> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /xmla=httpSessionContextIntegrationFilter ,basicProcessingFilter ,JIAuthenticationSynchronizer ,anonymousProcessingFilter ,basicAuthExceptionTranslationFilter ,filterInvocationInterceptor /services/**=httpSessionContextIntegrationFilter ,basicProcessingFilter ,JIAuthenticationSynchronizer ,anonymousProcessingFilter ,basicAuthExceptionTranslationFilter ,filterInvocationInterceptor /j_acegi_cas_security_check=httpSessionContextIntegrationFilter ,authenticationProcessingFilter ,anonymousProcessingFilter ,exceptionTranslationFilter ,filterInvocationInterceptor /**=httpSessionContextIntegrationFilter ,userPreferencesFilter ,authenticationProcessingFilter ,basicProcessingFilter ,JIAuthenticationSynchronizer ,anonymousProcessingFilter ,exceptionTranslationFilter ,filterInvocationInterceptor </value> </property></bean> Note the additional line for /j_acegi_cas_security_check. Add the casAuthenticationProvider and its necessary support beans to resemble the following <bean class="org.acegisecurity.providers.cas.CasAuthenticationProvider" id="casAuthenticationProvider"> <property name="casAuthoritiesPopulator"> <ref local="casDaoAuthorityPopulator" /> </property> <property name="casProxyDecider"> <bean class="org.acegisecurity.providers.cas.proxy.AcceptAnyCasProxy" /> </property> <property name="ticketValidator"> <ref local="casTicketValidator" /> </property> <property name="statelessTicketCache"> <bean class="org.acegisecurity.providers.cas.cache.EhCacheBasedTicketCache"> <property name="cache"> <ref local="ticketCache" /> </property> </bean> </property> <property name="key"> <value>lam_or_lame</value> </property></bean><bean class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" id="ticketCacheManager"> <property name="configLocation"> <value>classpath:/ehcache-failsafe.xml</value> </property></bean><bean class="org.springframework.cache.ehcache.EhCacheFactoryBean" id="ticketCache"> <property name="cacheManager"> <ref local="ticketCacheManager" /> </property> <property name="cacheName"> <value>casTicketCache</value> </property></bean><bean class="org.acegisecurity.providers.cas.ticketvalidator.CasProxyTicketValidator" id="casTicketValidator"> <property name="casValidate"> <value>https://localhost:8443/cas/proxyValidate</value> </property> <property name="serviceProperties"> <ref local="authenticationServiceProperties" /> </property></bean><bean class="org.acegisecurity.providers.cas.populator.DaoCasAuthoritiesPopulator" id="casDaoAuthorityPopulator"> <property name="userDetailsService"> <ref local="casUserAuthorityService" /> </property></bean><bean class="com.jaspersoft.jasperserver.api.metadata.user.service.impl.UserDetailsServiceImpl" id="casUserAuthorityService"> <property name="adminUsers"> <list> <value>tomcat</value> </list> </property> <property name="defaultAdminRoles"> <list> <value>ROLE_USER</value> <value>ROLE_ADMINISTRATOR</value> </list> </property> <property name="defaultInternalRoles"> <list> <value>ROLE_USER</value> </list> </property></bean> CAS only handles authentication, not authorization. The last section in the snippet above contains a list of usernames that should be considered admins, the JasperServer roles to give those users, and the roles to give everybody else. Finally, we need to redo the authenticationProcessingFilter and the authenticationProcessingFilterEntryPoint for CAS. Replace the existing entries with <bean class="org.acegisecurity.ui.cas.ServiceProperties" id="authenticationServiceProperties"> <property name="service"> <value>https://localhost:8443/jasperserver1_2/j_acegi_cas_security_check</value> </property> <property name="sendRenew"> <value>false</value> </property></bean><bean class="org.acegisecurity.ui.cas.CasProcessingFilter" id="authenticationProcessingFilter"> <property name="authenticationManager"> <ref local="authenticationManager" /> </property> <property name="authenticationFailureUrl"> <value>/loginerror.html</value> </property> <property name="defaultTargetUrl"> <value>/loginsuccess.html</value> </property> <property name="filterProcessesUrl"> <value>/j_acegi_cas_security_check</value> </property></bean><bean class="org.acegisecurity.ui.cas.CasProcessingFilterEntryPoint" id="authenticationProcessingFilterEntryPoint"> <property name="loginUrl"> <value>https://localhost:8443/cas/login</value> </property> <property name="serviceProperties"> <ref local="authenticationServiceProperties" /> </property></bean> The service property of the authenticationServiceProperties should point to the client web application, and is the URL that the CAS server will redirect to. Now restart tomcat and try logging into JasperServer. You should get the CAS login screen.

IntroductionJasperReports Server relies on Spring Security (Acegi) for much of its permissions and security functionality. By default JasperReports Server has the following permission levels: No AccessAdministerRead OnlyDelete + ReadWrite + Delete + ReadThese permissions may be assigned based on role or user id. It's more common to set permissions based on role, but both are equally valid. We had a customer requirement to offer the permission "Read + Write" (but not delete). By referring to Acegi documentation it's clear that this is possible. But the details aren't obvious for new Jaspersoft users. ExampleGoal: enable Read + Write permission in JasperReports Server. The main page involved is This page's main job is to render the GUI that lets an admin assign Permissions to resources based on Role. It gets the "permission" attribute and manipulates it by bitwise operations treating the integer as a base2 encoding of the permissions inherited from its parent and its directly set permissions. This is a common way to treat permissions. The following snippet shows how the choice "Delete + Read" gets generated. Why does "9216" refer to "Delete + Read"? Why does the dropdown sometimes have the value "18" instead of "9216"? Armed with that example, we can create a new entry for "Read + Write" AttachmentsThe attached Zip file, permissions.zip, contains jasperserver_messages.properties and ObjPermissionToRole.jsp.

[toc on_off::hide=0] The Jaspersoft Community Wiki is the online home of experience-based best practices and examples for the use of Jaspersoft products. The community of contributors may include Jaspersoft employees, partners, customers, and community members providing information based on experience and technical knowledge. The structure of this site, being a wiki, allows anyone with the appropriate access to alter the content found here. The purpose of this wiki is to provide a resource of best practices, examples, guides, and experiences to help Jaspersoft customers get the most out of and succeed with Jaspersoft products. The content is not necessarily reviewed for accuracy or supported features, and may include undocumented workarounds and user experiences. The content of any given information may recently have been changed, vandalized or altered by someone whose opinion does not correspond with the current functionality documented by Jaspersoft or recommended use of that functionality. NOTE: Find out more about the New TIBCO Community here.

In certain scenarios, where JasperReports Server Professional is integrated with your own application, there may be a need to programmatically clear the Ad Hoc cache in JasperReports Server when you recognize that the user has done something to change the set of data they are working with within your application. (i.e. a change in role, etc.). This article covers one possible way that this might be handled - by adding a custom cache key. Adding a Custom Cache KeyNote:This method only would apply to v3.1 or v3.5 of JasperReports Server Professional and since it is not a documented feature is subject to changes in implementation. In many cases, the need for this may be eleviated through the use of Multi-tenancy that was released in v3.5 of JasperReports Server Professional. There is a CacheKeyInterceptor interface that can modify the keys used by the Ad Hoc cache. It may be possible to modify the default key interceptor to include the value of a custom key in cache keys, so that a query with the same user id but a different custom key value would be kept separate. Having a static method to get its value makes it easy to implement the fix using the following steps: Step 1: Subclass DefaultCacheKeyInterceptor(com.jaspersoft.commons.datarator.DefaultCacheKeyInterceptor) In the implementation of getCacheKeyCalled(), extract the map containing query parameters and add the custom_cache_key value: package my.custom.code; import java.util.Map;import com.jaspersoft.commons.datarator.jr.JRDataSourceAdapter;import com.jaspersoft.commons.datarator.DefaultCacheKeyInterceptor;public class CharityIdAddingCacheKeyInterceptor extends DefaultCacheKeyInterceptor { public Object getCacheKeyCalled(Object key) { // call superclass, cast to map Map keyMap = (Map) super.getCacheKeyCalled(key);; Map paramMap = (Map) keyMap.get(JRDataSourceAdapter.PARAMS); // put charity id in map paramMap.put("charity_id", "plug in static call to get custom cache key here"); return keyMap; }} Step 2: Modify the Spring Config to use the new CacheKeyInterceptorIn WEB-INF/applicationContext-adhoc.xml, find the keyInterceptor property of the dataSetCache bean, which will look something like this: <!-- keyInterceptor: a class implementing CacheKeyInterceptor which can modify the cache keys --><property name="keyInterceptor"> <bean class="com.jaspersoft.commons.datarator.DefaultCacheKeyInterceptor"> Change the class to your new implementation and leave everything else the same: <property name="keyInterceptor"> <bean class="my.custom.code.CharityIdAddingCacheKeyInterceptor"> Step 3: TestYou can verify that it works by looking at the details of the Ad Hoc cache entries--you should see your new custom cache key parameter.