|
|
You're in the
sql server reporting services
group:ReportViewer + Screen Scraping ?
sql server reporting services:
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 [quoted text, click to view] "Sebastian Talamoni" <sebastian.talamoni@radventure.nl> wrote in message readHtmlPage("http://localhost/ReportServer?/MyFolder/MyReport&MyParameter=1news:%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 = > 36&MyPar2=1&rc:Stylesheet=htmlviewer&rs:Command=Render&rc:parameters=false") ; [quoted text, click to view] > } > > 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 -------------------------------------- [quoted text, click to view] "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> --> > >
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. [quoted text, click to view] "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 > >
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> -->
[quoted text, click to view]
> 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
[quoted text, click to view]
> 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...) [quoted text, click to view] > 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
Thanks Bruce, do you know of any temporary workaround to that scenario i've
mention? Sebastian [quoted text, click to view] "Bruce L-C [MVP]" <bruce_lcNOSPAM@hotmail.com> wrote in message news:%2379Otlr7EHA.3596@TK2MSFTNGP12.phx.gbl... > Next beta, not this beta,
[quoted text, click to view]
> 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 -------------------------------------- [quoted text, click to view] "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 > > >
[quoted text, click to view]
> 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) [quoted text, click to view] > 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 -------------------------------------- [quoted text, click to view] "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 >
[quoted text, click to view]
> 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 -------------------------------------- [quoted text, click to view] "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 [quoted text, click to view] "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 > \
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |