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?
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.
Related
I currently have a workshop module that allows users to view a set of objects and then filter them according to a filter widget.
I would like my users to be able to set which filters are applied via URL such that they can quickly apply their default filters.
How can I achieve this?
Create a variable for each filter you would like the user to be able to apply via URL.
Promote the variable so that it can be update via the URL.
Update the filter output to use the variables you created above.
In addition to using the promoted variables described in the answer above, specifically for the case of saving and re-using Filter state, you can enable the State Saving feature for users of your app, which allows them to snapshot and save specific application state as a separate Foundry resource. You can then share the link or bookmark or re-open from a folder without worrying about the "wiring" of variables and URL parameters.
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).
So I have a report in Reporting Services 2005. In it is one parameter (ConnectionString) which determines which data source the report will use. It also has several other parameters which are dropdown lists derived from the data source chosen in the ConnectionString parameter.
In Report Manager, this works great. All of the dropdowns are greyed out at the beginning. When you choose your data source, the page requeries/repaints and all of the available parameter values for the other parameters are filled in based on the queries for those fields.
However ...
In the ReportViewer web control, when the report is first loaded up, instead of dropdown boxes all of the other parameter fields are just empty textboxes. Choosing a different data source for the ConnectionString parameter doesn't requery/repaint the other parameters.
I've been flipping through the ReportViewer programming reference to see if there's some way to replicate the Report Manager's way of reloading the webpage with the report viewer upon certain parameter changes, but I can't find anything there that isn't over my poor little .NET head.
Any ideas?
Not sure if this is any help but I do have a suggestion. I would try pulling the logic for dropdown boxes out of the report and put them in an ASP.net page. Then pass the parameters to the report and control the rendering/refreshing.
HTH
UPDATE: So it turns out you must provide a default value for any parameters which in turn affect other parameters in your report in order to get the dropdown box to load properly on initialization. Also note this is recursive - so if you have a parameter which affects another parameter which affects another parameter, both the first and second parameter must have default values.
What's the best way to handle translations for stock text in a SSRS. For instance - if I have a report that shows a grid of contents what's the best way to have the correct translation for the header of that grid show up, assuming the culture of the report is set correctly.
Put another way - is it possible to do resources in a SSRS report, or am I stuck with storing all that text in the database and querying for it?
AS far as I know, there is no way to localize a report (meaning automating the translation of string litterals)...
Like you said,you basically have to use the User!Language global variable to catch the user's settings and then use that to retrieve the appropriate strings from the DB...
However, you can adapt the display of currency/numeric/date fields according to the user locale. Also possible is changing the interface of the Report Viewer to match your user's langage.
Here are a few links giving tips on how to adapt the locale:
http://www.ssw.com.au/Ssw/Standards/Rules/RulesToBetterSQLReportingServices.aspx#LanguageSetting
Langage pack for Report Viewer:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e3d3071b-d919-4ff9-9696-c11d312a36a0