<Edit: Sorry, can't change the thread name after the fact. I meant 'ReportViewer'>
We have a customer using an older version of the ReportViewer. We are attempting to implement an SSL offload solution, and the following code is generated on their page:
<script type="text/javascript">
var ReportViewer1 = new ReportViewer('ReportViewer1','ReportViewer1_ReportToolbar','ReportViewer1_ctl00','ReportViewer1_ctl01_ReportFrame','ReportViewer1_ctl01_PreviewFrame','ReportViewer1_CP', 'http://192.168.1.1:80/Telerik.ReportViewer.axd?instanceid=ca040209b9c8etc&optype=Report', 'http://192.168.1.1:80/Telerik.ReportViewer.axd?instanceid=ca040209b9c8etc&optype=Export', 'http://192.168.1.1:80/Telerik.ReportViewer.axd?instanceid=ca040209b9c8etc&optype=Print', 'Percent', '100', '');
</script>
The traffic has been decrypted on the outside, and sent to the server on port 80. Everything else is using relative links, so the majority of traffic returns as https://192.168.1.1/foo.aspx
These specific resources cause the browser to attempt to connect on port 80, and triggers a popup "This page contains both secure and non-secure items."
They are using version 2.0.0.0.
Ideally, I'd like to present one of two options:
1. They upgrade to the latest version of the ReportViewer, with an assurance that this behavior will not take place. I don't want to put them through the pain of changing their code if it won't fix the problem.
2. There is a workaround within their version that does not write the absolute path on the page.
If there are any other solutions, I'd be happy to hear them. I'm assuming this must have been a common problem for anyone who has tried to convert their sites to SSL.
Thanks.
We have a customer using an older version of the ReportViewer. We are attempting to implement an SSL offload solution, and the following code is generated on their page:
<script type="text/javascript">
var ReportViewer1 = new ReportViewer('ReportViewer1','ReportViewer1_ReportToolbar','ReportViewer1_ctl00','ReportViewer1_ctl01_ReportFrame','ReportViewer1_ctl01_PreviewFrame','ReportViewer1_CP', 'http://192.168.1.1:80/Telerik.ReportViewer.axd?instanceid=ca040209b9c8etc&optype=Report', 'http://192.168.1.1:80/Telerik.ReportViewer.axd?instanceid=ca040209b9c8etc&optype=Export', 'http://192.168.1.1:80/Telerik.ReportViewer.axd?instanceid=ca040209b9c8etc&optype=Print', 'Percent', '100', '');
</script>
The traffic has been decrypted on the outside, and sent to the server on port 80. Everything else is using relative links, so the majority of traffic returns as https://192.168.1.1/foo.aspx
These specific resources cause the browser to attempt to connect on port 80, and triggers a popup "This page contains both secure and non-secure items."
They are using version 2.0.0.0.
Ideally, I'd like to present one of two options:
1. They upgrade to the latest version of the ReportViewer, with an assurance that this behavior will not take place. I don't want to put them through the pain of changing their code if it won't fix the problem.
2. There is a workaround within their version that does not write the absolute path on the page.
If there are any other solutions, I'd be happy to hear them. I'm assuming this must have been a common problem for anyone who has tried to convert their sites to SSL.
Thanks.
2 Answers, 1 is accepted
0
Accepted
Hi Chris,
I've installed SelfSSL to test if we're indeed throwing "This page contains both secure and non-secure items" warning. However I was not able to replicate this on our end (see attached screenshot) with the latest official version. First verify if the problem is indeed caused by the ReportViewer control, by removing other irrelevant controls from the page and test with the latest version to see if this is the case.
Kind regards,
Steve
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
I've installed SelfSSL to test if we're indeed throwing "This page contains both secure and non-secure items" warning. However I was not able to replicate this on our end (see attached screenshot) with the latest official version. First verify if the problem is indeed caused by the ReportViewer control, by removing other irrelevant controls from the page and test with the latest version to see if this is the case.
Kind regards,
Steve
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
Chris
Top achievements
Rank 1
Rank 1
answered on 09 Mar 2009, 04:16 PM
Thanks for looking into it. They did upgrade to the latest version of the controls, the links are now generated as relative links, and the problem is solved.