Hello,
We have an intranet app which is created by a group of developers. The app has buttons to invoke reports. They don't want to embed rdl files into Web app but want to render reports using the url and passing the required parameters. Since none of the people in our team is expert in Reporting Services I would appreciate some advice on the following:
1. Is the url rendering easier than using embedded reports when it comes to deploying and maintaining the reports
2. How about the security Firewalls etc How to impletement the security
3. Which account should these reports be run under e.g. local system account or domain account
Thanks
Daps
URL rending vs embedded reports
bcsanches
Kel Koenig
In any event, you may have some security issues because when you are running in your own web app, depending on the security mechanism that's implemented. In our prototype app, we are still using NTLM and Windows Authentication on the web app, and therefore the end-user's id is not passed from the web server to RS. So we use impersonation in the web app with a dummy user, and grant the dummy user security within RS.
Jim
kwigibo
For example, I wanted to know if one dataset returns data or not, in that case , to show the report, or not will be more easy from .net, in my point of view, I also think that impersonation is easier to implement with the webservice than with reportviewer.
Another thing that I wanted to control is the rendering extensions, I wanted only to give EXCEL and PDF, not the others.
Medackel
If you embed using a URL you get simplicity (it is really easy to do), but you have to determine how the user is shown the report. Two general approaches:
1) a custom web control is added to the ASP.Net page to host the raw HTML produced by the report server - this is clunky
2) an IFrame is added or a new browser windows is launched to display the report. This means the user is accessing the report server directly (no within your application). As such each user needs to have permissions to view the report. It also means that all users need access to the report server computer.
If you embed using the Report Viewer control, users never access the report server directly. This is good from a security perspective. In your application, you get to choose which credentials are used to access the report - whether it is the end user's credential or your applications. This allows you to choose wether users can access reports directly or only through your application. This choice allows you to better control the surface area of your solution. The report viewer makes it really easy to provide a good user experience for navigating/interacting with the report in your application. Unlike the custom web control approach above, using the report viewer you have to write almost no code to make this work. Using the Report Viewer control you get to write against an API to manipualate default parameter values, etc. If you want to do this using URL access you would have to build the URLs manually.
One "drawback" from a configuration viewpoint - if use use a report viewer control to access a report on a report serfver, you have an extra hop between the user and the report server. If you want to use windows integrated security to access reports or data in data sources used by your reports, you'll usually need to configure kerberos.
Hope that helps,
-Lukasz
r.parker
Great thanks. I'll pass along the feedback to other members of the team.
-Lukasz
George Cooper
Hi Luis,
Can you elaborate on the kinds of style controls you wanted to have in your application With the ReportViewer you can turn off all the parameters areas, etc and just show the report. Is this not enough, or are you actually manipulating the HTML that is returned by the report server
-Lukasz
John Blight
I think that my new article will be very useful for you
Check it at
http://levalenciam.spaces.msn.com/
I dont use Iframes, I use the ReportExecutionService.asmx WebService to render the repot inside the browser with no reportviewer, reportviewer is cool but it didnt satisfy the clientes requierements and it didnt fit the design of my application.
When you read the article please ask any questions.
Littel_Pooh
Thanks for your info Jim.
At this point I am wondering what is the benefit of using embedded report viewer as opposed to url rendering. I liked the idea of using impersonation with a dummy user and granting security to that user within Rs.
thanks.
Daps
Vino Varkey
Also, I forgot to mention that the Intranet app and Report Server will be residing on different boxes. How is the identity impersonate works in the scenario What would be the best practice to implement security
Thanks
Daps