B
Brendan Reynolds
I'm trying to integrate SQL Server Reporting Services reports into an
ASP.NET app (SRS 2000, ASP.NET 1.1). I know how to do this using direct URL
addressing, but this exposes in the query string parameters that should not
be exposed. Each user is associated with a school, and should see only that
school's data. When the user logs in, I retrieve the SchoolID associated
with that user, and that SchoolID is used as a parameter in all stored
procedures to return only that school's data. It is this SchoolID that needs
to be passed to the report. It doesn't matter if users see the SchoolID, but
they must not be able to change the SchoolID, as they can if it forms part
of the URL.
From the documentation and from previous discussions in the SRS newsgroup,
it appears that there are four possible solutions to this:
1) Wait for SRS 2005 which I understand is due in November.
2) Use the web service instead of URL access and write a lot of code to
provide functionality you get built-in when using URL access.
3) Use URL access through a form POST method, as suggested in SRS Books
Online
(http://msdn.microsoft.com/library/en-us/RSPROG/htm/rsp_prog_intro_35pi.asp)
4) Require users to log in again when accessing reports, despite having
already logged in to the ASP.NET app. The report would prompt the user for
user name and password, and pass these to the stored procedures instead of
the SchoolID. This would avoid having to pass the SchoolID from the ASP.NET
app to the reports, but I'm not sure that the users will accept the
inconvenience. (The passwords are of course stored in encrypted form, so
I'll need to add code to the reports to encrypt the password supplied by the
user, but that's a separate issue.)
My questions are:
1) Can anyone confirm that the next version really does solve this problem?
2) Any pointers to resources on using the web service, particularly on how
to control rendering and how to reproduce the functionality of the toolbar
you get when using URL access, would be welcome. (I already know about SRS
Books Online and the articles reachable from the MSDN SQL Server Developer
Center).
3) Can I use the POST method as suggested in SRS Books Online from within an
ASP.NET app? I thought an ASP.NET page could only post back to itself, is
that not so?
Please don't feel that you have to have answers to all of these questions
before responding - suggestions or advice regarding any part of the problem
would be most welcome.
ASP.NET app (SRS 2000, ASP.NET 1.1). I know how to do this using direct URL
addressing, but this exposes in the query string parameters that should not
be exposed. Each user is associated with a school, and should see only that
school's data. When the user logs in, I retrieve the SchoolID associated
with that user, and that SchoolID is used as a parameter in all stored
procedures to return only that school's data. It is this SchoolID that needs
to be passed to the report. It doesn't matter if users see the SchoolID, but
they must not be able to change the SchoolID, as they can if it forms part
of the URL.
From the documentation and from previous discussions in the SRS newsgroup,
it appears that there are four possible solutions to this:
1) Wait for SRS 2005 which I understand is due in November.
2) Use the web service instead of URL access and write a lot of code to
provide functionality you get built-in when using URL access.
3) Use URL access through a form POST method, as suggested in SRS Books
Online
(http://msdn.microsoft.com/library/en-us/RSPROG/htm/rsp_prog_intro_35pi.asp)
4) Require users to log in again when accessing reports, despite having
already logged in to the ASP.NET app. The report would prompt the user for
user name and password, and pass these to the stored procedures instead of
the SchoolID. This would avoid having to pass the SchoolID from the ASP.NET
app to the reports, but I'm not sure that the users will accept the
inconvenience. (The passwords are of course stored in encrypted form, so
I'll need to add code to the reports to encrypt the password supplied by the
user, but that's a separate issue.)
My questions are:
1) Can anyone confirm that the next version really does solve this problem?
2) Any pointers to resources on using the web service, particularly on how
to control rendering and how to reproduce the functionality of the toolbar
you get when using URL access, would be welcome. (I already know about SRS
Books Online and the articles reachable from the MSDN SQL Server Developer
Center).
3) Can I use the POST method as suggested in SRS Books Online from within an
ASP.NET app? I thought an ASP.NET page could only post back to itself, is
that not so?
Please don't feel that you have to have answers to all of these questions
before responding - suggestions or advice regarding any part of the problem
would be most welcome.