|
ChartDir for asp.net, Graph doesn't appear on Production |
Posted by Leo on May-24-2012 17:42 |
|
Hi,
First of all, I wish to state that ChartDirector component for asp.net is perfect, pluggable and great for achieving its goals with maximum simplicity, once you research all of its capabilities.
We have a site that we've redesigned. In the old site we have a graph that is rendered on its own in a special page. In the current design we put it inside a repeater, a custom web control and dynamically inside an UpdatePanel (which is rendered using a partial postback).
Now, in developement environment it works fine - all necessary graphs appear and reappear within all necessary rows of the repeater (and in minimum time, I might add, which is great). But, in production environment the graph doesn't appear (and it shows a red 'X' instead, as if the chart image isn't there). In Chrome Developer Tools in production the Console says: "Error 403 - forbidden" (In developement there are no messages within the Chrome's Console).
The difference between the environments is that we've installed a certificate (SSL) in production.
We check the permissions and saw "Everyone - Read, Everyone - Read & Execute". Also we added the same permission for the web server and the ASP.NET user and anonymous user.
Nothing seems to work.
One solution I can try is to use an Image handler instead of partial postback (though it will not be quite useful, since the whole graph contains private and confidential data for the current user).
Will it work? if no, What can I do in order to resolve the issue?
Thanks in advance,
Leo |
Re: ChartDir for asp.net, Graph doesn't appear on Production |
Posted by Peter Kwan on May-24-2012 23:22 |
|
Hi Leo,
First, we need to find out the exact issue why the browser cannot display the image. We need to confirm if it is really "Error 403 - forbidden". If it is really "Error 403 - forbidden", we need to find out why the server denies the access.
The "Error 403 - forbidden" should be a response from the server to avoid the HTTP requests to get process by the server ASP.NET system. As the HTTP request is not processed at all by the ASP.NET system, it should not be caused by the ASP.NET code that handles the requests.
To trouble-shoot the problem, you can try to go into the "red X" (broken image symbol) to get the error message inside. This can confirm if it is really an "Error 403". See:
http://www.chartdir.com/forum/download_thread.php?site=chartdir&bn=chartdir_faq&thread=1117817200
(I have not tried the Chrome Console itself. May be the message it is displayed is already the error message inside the "red X".)
If it is really an "Error 403", we need to determine why the server denies the request. Does the server has some error log or access log (it should have such log files) that explains why it denies the request? Usually, the server will not tell the browser why it denies the request, but it may log the reason in some log files. For example, may be the server does not like the structure of the URL, or the server may believe the HTTP request to get the image is from a different user, or the server has difficulty using session variables. Another possibility is that there are actually multiple servers or server processes (eg. using server farms or server gardens), and the user logs in to one of the server or server process, but the image requests for some reason is routed to another server or server process which does not know the user has already logged in.
Once you know why the server denies the request, you may be able to configure the server not to deny it.
If you do not bother to find out why the server denies the request, one common method is to create the chart as a temporary file on the hard disk using BaseChart.makeTmpFile. In many systems, access to image files may not be checked so seriously for security, and so the server may permit such access. However, using this method means you are by-passing the server's security check to solve the problem, so it may be less secure as the server may allow other people to look at the images as well, provided they somehow know the randomly generated temporary file name.
Regards
Peter Kwan |
|