0

We are currently using a generic report which will be used differently by multiple usergroups. We have made this possible by creating linked reports with different settings of hidden parameters (such as 'show column x', 'enable feature y'). These settings (parameters) are needed on other reports as well, so we pass them along using the Go to ... Action.

To create the look and feel we are after, we are passing some additional parameters as well, HTML Viewer commands and Report Server commands such as &rc:Parameters=False (reference).

Unfortunately, this leaves us with only the option Go to URL, since Microsoft hasn't implemented these commands for Go to Report. This means we have to pass our settings (the hidden parameters) along in the URL. This results in a security issue, example given: &PARAMETER_ENABLE_FEATURE_Y=False.

The user might notice this parameter in the URL and is so given the possibility to enable this function by editing the URL to &PARAMETER_ENABLE_FEATURE_Y=True.

So my question is: how to use an Action in Reporting Services while preventing users from editing our sensitive parameters and while being able to use HTML Viewer commands and Report Server commands?

Menno
  • 12,175
  • 14
  • 56
  • 88
  • You can call a report by using POST instead of GET. POST puts the parameters into the body of the post instead of on the URL (which is what GET does). You can probably do this using javascript. However: a user can still see the post parameters by using F12 tools, and worse... for some reason SSRS then turns the post into a GET so you see them on the URL anyway – Nick.Mc Dec 20 '16 at 10:26

1 Answers1

1

You will never get complete security in this sense if you absolutely have to use URL based parameters.

When navigating via the URL, the only way you can hide parameter values without hard coding them is to make them data driven. In your scenario however this will not be 100% secure as you will still need to pass the value that populates your data driven parameters.

This level of obfuscation is probably enough and can be achieved by collating a list of either every parameter combination or just the ones your need and assigning it an ID that you can call in a dataset. This can obviously still be changed by your users should they get curious and can be a faff to maintain.

I would say your only other option is to hide the URL bar completely by providing a 'landing page' for your reporting and displaying everything in an iframe. This frame can be targeted with a javascript link in your Go To URL:

="javascript:void(window.open('URL to open','iFrame Name'))"

If you are able to though, I would advise you group your users into Active Directory security groups and then maintain a collection of permissions and customisations per group. You can then check which groups a user is a part of using custom code similar to the answers here and return the required parameter values accordingly.

Doing things this way will also enable you to maintain which groups can see what from a central location, assuming you have rolled out the same parameter structure across all reports.

Community
  • 1
  • 1
iamdave
  • 12,023
  • 3
  • 24
  • 53
  • Thank you very much. I decided to move a set of parameters to a configurationtable, where depending on the `Active Directory group` a value is returned and used as `default value`. A few other parameters will remain in the URL, since they indicate the selected date, costcenter and so on. For these parameters I have made sure that the `available values` are valid for the context of the user. – Menno Dec 20 '16 at 14:15