Hi,
I've been following the newsgroup with great interest but this is my first
posting.
There are hundreds of messages regarding the following scenario:
ASP.NET + ReportViewer.dll + Reports using sensible parameters +
Subscriptions on those same reports + "I do not want to loose interactive
features from the ReportViewer"
Now, here are the facts:
a) because of the subscriptions you can't use WebForms authentication
b) SOAP API looses interactive features.
c) We can not use windows authentication because the application security is
WebForm security using custom db tables, etc. (remmember issue in (a)).
So, thanks a collegue of mine we came to this conclusion:
What if we use screen scaping of the Report URL.
Advantages:
1) the URL is not visible since it's done in the server side
2) Special credential could be used for the httprequest.
The Code still does not work because the output HTML uses URL reference back
that would need to be "translated with a proxy".
Has anybody already tried this?
Is this a bad approach for any special reason?
Thanks in advance,
Sebastian Talamoni
-- Example Screen Scrapgin Code using --
<%@. Import Namespace="System.Net" %>
<%@. Import Namespace="System.IO" %>
<script language="C#" runat="server">
void Page_Load(Object Src, EventArgs E) {
myPage.Text = readHtmlPage("http://localhost/ReportServer?/MyFolder/MyReport&MyParameter=136&MyPar2=1&rc:Stylesheet=htmlviewer&rs:Command=Render&rc:parameters=false");
}
private String readHtmlPage(string url) {
String result;
WebResponse objResponse;
HttpWebRequest objRequest = (HttpWebRequest)
System.Net.HttpWebRequest.Create(url);
objRequest.Credentials = new NetworkCredential("yourUserName",
"yourPassword", "YourDOMAIN") ;
objRequest.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
5.1; .NET CLR 1.1.4322)";
objResponse = objRequest.GetResponse();
using (StreamReader sr = new
StreamReader(objResponse.GetResponseStream()) ) {
result = sr.ReadToEnd(); // Close and clean up the
StreamReader
sr.Close();
}
return result;
}
</script>
<!-- <html>
<body> -->
<asp:literal id="myPage" runat="server"/>
<!-- </body>
</html> -->Here is another idea depending on when you need this. The next beta of
Widbey will have the webform and winform controls for RS. I expect that this
release will have a go-live license. I am thinking that using the control
will give you much more flexibility in this area.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Sebastian Talamoni" <sebastian.talamoni@.radventure.nl> wrote in message
news:%23mRBzjo7EHA.1296@.TK2MSFTNGP10.phx.gbl...
> Hi,
> I've been following the newsgroup with great interest but this is my first
> posting.
> There are hundreds of messages regarding the following scenario:
> ASP.NET + ReportViewer.dll + Reports using sensible parameters +
> Subscriptions on those same reports + "I do not want to loose interactive
> features from the ReportViewer"
> Now, here are the facts:
> a) because of the subscriptions you can't use WebForms authentication
> b) SOAP API looses interactive features.
> c) We can not use windows authentication because the application security
is
> WebForm security using custom db tables, etc. (remmember issue in (a)).
> So, thanks a collegue of mine we came to this conclusion:
> What if we use screen scaping of the Report URL.
> Advantages:
> 1) the URL is not visible since it's done in the server side
> 2) Special credential could be used for the httprequest.
> The Code still does not work because the output HTML uses URL reference
back
> that would need to be "translated with a proxy".
> Has anybody already tried this?
> Is this a bad approach for any special reason?
> Thanks in advance,
> Sebastian Talamoni
>
> -- Example Screen Scrapgin Code using --
> <%@. Import Namespace="System.Net" %>
> <%@. Import Namespace="System.IO" %>
> <script language="C#" runat="server">
> void Page_Load(Object Src, EventArgs E) {
> myPage.Text =>
readHtmlPage("http://localhost/ReportServer?/MyFolder/MyReport&MyParameter=1
36&MyPar2=1&rc:Stylesheet=htmlviewer&rs:Command=Render&rc:parameters=false")
;
> }
> private String readHtmlPage(string url) {
> String result;
> WebResponse objResponse;
> HttpWebRequest objRequest = (HttpWebRequest)
> System.Net.HttpWebRequest.Create(url);
> objRequest.Credentials = new NetworkCredential("yourUserName",
> "yourPassword", "YourDOMAIN") ;
> objRequest.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
> 5.1; .NET CLR 1.1.4322)";
> objResponse = objRequest.GetResponse();
> using (StreamReader sr = new
> StreamReader(objResponse.GetResponseStream()) ) {
> result = sr.ReadToEnd(); // Close and clean up the
> StreamReader
> sr.Close();
> }
> return result;
> }
> </script>
> <!-- <html>
> <body> -->
> <asp:literal id="myPage" runat="server"/>
> <!-- </body>
> </html> -->
>|||Why do you want screen scraping?
You can tweak the ReportViewer to work with interactive reports. Is it
the subscriptions part that's breaking this solution?
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Sebastian Talamoni" <sebastian.talamoni@.radventure.nl> wrote in message
news:%23mRBzjo7EHA.1296@.TK2MSFTNGP10.phx.gbl...
> Hi,
> I've been following the newsgroup with great interest but this is my first
> posting.
> There are hundreds of messages regarding the following scenario:
> ASP.NET + ReportViewer.dll + Reports using sensible parameters +
> Subscriptions on those same reports + "I do not want to loose interactive
> features from the ReportViewer"
> Now, here are the facts:
> a) because of the subscriptions you can't use WebForms authentication
> b) SOAP API looses interactive features.
> c) We can not use windows authentication because the application security
> is WebForm security using custom db tables, etc. (remmember issue in (a)).
> So, thanks a collegue of mine we came to this conclusion:
> What if we use screen scaping of the Report URL.
> Advantages:
> 1) the URL is not visible since it's done in the server side
> 2) Special credential could be used for the httprequest.
> The Code still does not work because the output HTML uses URL reference
> back that would need to be "translated with a proxy".
> Has anybody already tried this?
> Is this a bad approach for any special reason?
> Thanks in advance,
> Sebastian Talamoni
>
> -- Example Screen Scrapgin Code using --
> <%@. Import Namespace="System.Net" %>
> <%@. Import Namespace="System.IO" %>
> <script language="C#" runat="server">
> void Page_Load(Object Src, EventArgs E) {
> myPage.Text => readHtmlPage("http://localhost/ReportServer?/MyFolder/MyReport&MyParameter=136&MyPar2=1&rc:Stylesheet=htmlviewer&rs:Command=Render&rc:parameters=false");
> }
> private String readHtmlPage(string url) {
> String result;
> WebResponse objResponse;
> HttpWebRequest objRequest = (HttpWebRequest)
> System.Net.HttpWebRequest.Create(url);
> objRequest.Credentials = new NetworkCredential("yourUserName",
> "yourPassword", "YourDOMAIN") ;
> objRequest.UserAgent = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT
> 5.1; .NET CLR 1.1.4322)";
> objResponse = objRequest.GetResponse();
> using (StreamReader sr = new
> StreamReader(objResponse.GetResponseStream()) ) {
> result = sr.ReadToEnd(); // Close and clean up the
> StreamReader
> sr.Close();
> }
> return result;
> }
> </script>
> <!-- <html>
> <body> -->
> <asp:literal id="myPage" runat="server"/>
> <!-- </body>
> </html> -->
>|||> Here is another idea depending on when you need this. The next beta of
> Widbey will have the webform and winform controls for RS. I expect that
> this
> release will have a go-live license. I am thinking that using the control
> will give you much more flexibility in this area.
Thanks, i will also suggest this option, but the intention was to go live
ASAP.
BTW, i am beta testing whidbey (vs.2005 ) and did not saw anything with RS
yet...
Sebastian|||> Why do you want screen scraping?
Jeff,
First thanks for the feedback.
To be able to use the ReportViewer at server side without exposing the
report URL (and parameters). I think that with this technique we might
combine the 2 scenarios : security from server side ( since that http
request will run with special credentials and ReportServer will not be
available to internet users + parameters and URL hidden ) with the
advantages of interative toolbar features.. (this does not work yet, it's my
question...)
> You can tweak the ReportViewer to work with interactive reports. Is it
> the subscriptions part that's breaking this solution?
For example what tweaks? Is there any way to attach a special credential to
the iframe src ? (that could be another option that i thought it was not
possible..)
I only saw Teo's excellent examples , that off course loose the interative
feature as soon as you go to server mode.
Since the ReportViewer is based on URL syntax (and since we are not using
winform authentication (and also could not use webauthentication becasue
breaks subscriptions)) we are exposing the URL to any access.
Sebastian|||Next beta, not this beta,
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services of widbey will have the controls. Not sure
if you will in addition need the next beta of Yukon. The reason is I am not
sure if the controls will work with current version of RS or will need the
Yukon version. The controls will work stand alone or in conjunction with a
RS server.
"Sebastian Talamoni" <sebastian.talamoni@.radventure.nl> wrote in message
news:%236WQbdr7EHA.3416@.TK2MSFTNGP09.phx.gbl...
> > Here is another idea depending on when you need this. The next beta of
> > Widbey will have the webform and winform controls for RS. I expect that
> > this
> > release will have a go-live license. I am thinking that using the
control
> > will give you much more flexibility in this area.
> Thanks, i will also suggest this option, but the intention was to go live
> ASAP.
> BTW, i am beta testing whidbey (vs.2005 ) and did not saw anything with RS
> yet...
> Sebastian
>|||Thanks Bruce, do you know of any temporary workaround to that scenario i've
mention?
Sebastian
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%2379Otlr7EHA.3596@.TK2MSFTNGP12.phx.gbl...
> Next beta, not this beta,|||> Why do you want screen scraping?
Actually, I do not want screen scraping per-se but actually the concept of
having an intermediate server-sided proxy that re-uses the Previewer
features allowing windows authentication (on the httprequest) and as a side
effect does not expose the url + parameters.
Sebastian|||It sounds like your number one concern is to disallow direct URL access to
your reports. I'm not sure why, since there are plenty of mechanisms to
protect the data even with URL access.
Nevertheless, if you really need to hide the URL, you'll need to use the
SOAP interface to pull back the report HTML on the server side and drop it
into whatever web page/viewer you make. There is some serious complexity to
using SOAP, however; you'll need to stream any images back separately from
the report itself, which takes a bit of coding -- or some lucky grabs of
sample code online.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Sebastian Talamoni" <sebastian.talamoni@.radventure.nl> wrote in message
news:OH9zVer7EHA.3840@.tk2msftngp13.phx.gbl...
>> Why do you want screen scraping?
> Jeff,
> First thanks for the feedback.
> To be able to use the ReportViewer at server side without exposing the
> report URL (and parameters). I think that with this technique we might
> combine the 2 scenarios : security from server side ( since that http
> request will run with special credentials and ReportServer will not be
> available to internet users + parameters and URL hidden ) with the
> advantages of interative toolbar features.. (this does not work yet, it's
> my question...)
>> You can tweak the ReportViewer to work with interactive reports. Is it
>> the subscriptions part that's breaking this solution?
> For example what tweaks? Is there any way to attach a special credential
> to the iframe src ? (that could be another option that i thought it was
> not possible..)
> I only saw Teo's excellent examples , that off course loose the interative
> feature as soon as you go to server mode.
> Since the ReportViewer is based on URL syntax (and since we are not using
> winform authentication (and also could not use webauthentication becasue
> breaks subscriptions)) we are exposing the URL to any access.
> Sebastian
>
>|||> It sounds like your number one concern is to disallow direct URL access to
> your reports. I'm not sure why, since there are plenty of mechanisms to
> protect the data even with URL access.
Jeff, thanks for replying.
What mechanisms are you refering to?
The only one I found (and this is the one i am going to implement ) is to
use GUIDs as PK in order not to send "visible/sensitive" IDs through the
URL. So instead of sending CustomerID=3 (easy to change) we can send a GUID
making more difficult to get real reports out of it (i think).
The other technique i will try to implement is to have the "report" page
running with a different authentication that the rest of the website. So if
the URL is copied/pasted into a new browser it will not work since you are
not authenticated (you will need an extra pair of UID+PWD that is not the
same that you use to login to the website)
> Nevertheless, if you really need to hide the URL, you'll need to use the
> SOAP interface to pull back the report HTML on the server side and drop it
> into whatever web page/viewer you make. There is some serious complexity
> to using SOAP, however; you'll need to stream any images back separately
> from the report itself, which takes a bit of coding -- or some lucky grabs
> of sample code online.
I am already using SOAP for subscriptions integration, but I've stated in my
mail that using SOAP makes you loose the interactive features of the
ReportViewer and therefore unless there is a replacement for the
ReportViewer to use SOAP automatically (with the interactive features!) then
the problem is not solved.
Sebastian|||If you use SSL plus forms authentication, you should have plenty of
protection. What authentication is the rest of the web site using?
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Sebastian Talamoni" <sebastian.talamoni@.radventure.nl> wrote in message
news:ukaJ8kv9EHA.3640@.tk2msftngp13.phx.gbl...
>> It sounds like your number one concern is to disallow direct URL access
>> to your reports. I'm not sure why, since there are plenty of mechanisms
>> to protect the data even with URL access.
> Jeff, thanks for replying.
> What mechanisms are you refering to?
> The only one I found (and this is the one i am going to implement ) is to
> use GUIDs as PK in order not to send "visible/sensitive" IDs through the
> URL. So instead of sending CustomerID=3 (easy to change) we can send a
> GUID making more difficult to get real reports out of it (i think).
> The other technique i will try to implement is to have the "report" page
> running with a different authentication that the rest of the website. So
> if the URL is copied/pasted into a new browser it will not work since you
> are not authenticated (you will need an extra pair of UID+PWD that is not
> the same that you use to login to the website)
>
>> Nevertheless, if you really need to hide the URL, you'll need to use the
>> SOAP interface to pull back the report HTML on the server side and drop
>> it into whatever web page/viewer you make. There is some serious
>> complexity to using SOAP, however; you'll need to stream any images back
>> separately from the report itself, which takes a bit of coding -- or some
>> lucky grabs of sample code online.
> I am already using SOAP for subscriptions integration, but I've stated in
> my mail that using SOAP makes you loose the interactive features of the
> ReportViewer and therefore unless there is a replacement for the
> ReportViewer to use SOAP automatically (with the interactive features!)
> then the problem is not solved.
> Sebastian
>|||> If you use SSL plus forms authentication, you should have plenty of
> protection. What authentication is the rest of the web site using?
Jeff,
I think you are not considering the fact that I mention originally that we
can not use Forms Authentication (inside RS) because that will break
subscriptions.
The rest of the application is using Form Authentication.
Sebastian|||Writing your own subscriptions (delivery) mechanism would probably be easier
than writing a screen scraper. Scripting the execution, saving, and
e-mailing of reports is relatively simple. Note the word "relatively" -- in
my mind at least, compared with what you are asking.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Sebastian Talamoni" <sebastian.talamoni@.radventure.nl> wrote in message
news:uGtS5c%239EHA.3700@.tk2msftngp13.phx.gbl...
>> If you use SSL plus forms authentication, you should have plenty of
>> protection. What authentication is the rest of the web site using?
> Jeff,
> I think you are not considering the fact that I mention originally that we
> can not use Forms Authentication (inside RS) because that will break
> subscriptions.
> The rest of the application is using Form Authentication.
> Sebastian
>|||Thanks again Jeff,
I think RS is a great product but can not understand how this basic
combinations can not be done now without investing quite a lot of time.
Luckily MS is aware and future RS version will make this combination
simpler.
Actually i have a screen scraper version working but it fails on all the
postbacks (urls , javascripts) inside the buttons, so i think i will stop
since like you said it will be a lot of work to internally modify those
references.
Sebastian
"Jeff A. Stucker" <jeff@.mobilize.net> wrote in message
news:OZFYx$D%23EHA.1296@.TK2MSFTNGP10.phx.gbl...
> Writing your own subscriptions (delivery) mechanism would probably be
> easier than writing a screen scraper. Scripting the execution, saving,
> and e-mailing of reports is relatively simple. Note the word
> "relatively" -- in my mind at least, compared with what you are asking.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment