Our product includes a Flash application that is loaded by SWFObject. For one customer, when accessing this SWF via HTTPS (but not HTTP), Flash Player will not load it.
I asked the customer to go directly to the URL of the SWF file (rather than the wrapper page):
When he does so via HTTP, the SWF loads in the browser.
When he does so via HTTPS, IE7 presents him with a 'save file' dialog box. This implies that a "Content-Disposition: attachment" header is present in the response. That would also explain why the SWF isn't loading in Flash Player: as a security measure, it will not play SWFs served with that header.
So, I have a couple of things I'm trying to figure out:
How can I be certain that a Content-Disposition header is being sent by the server (rather than it being a strange artifact of IE7)? The user only has IE7 at his disposal, and cannot use Firefox, Chrome, etc. IE7 doesn't include the handy 'Network' tab that's present in IE9's developer tools.
Assuming that the header is present, how is it getting there? They are running Tomcat 6. The SWF is being served by Tomcat's default servlet. The header appears to be present if the HTTPS connector is used, but not if the HTTP connector is used. The Tomcat configuration is stock except for enabling the HTTPS connector.
On a side note, I don't trust Flash's cache clearing. On my machine under IE9, the SWF is often satisfied by cache even after I explicitly clear the browser cache and Flash Player's stored data: I don't see any request for it in Fiddler, or in Tomcat's access logs, but the SWF loads in the browser. Am I missing something here? Could the customer be accessing some bogus cached version of the SWF?
Edit: Apparently the 'clear cache' command in the developer tools doesn't really clear the cache. Using the standard method yielded the expected results.
Edit 2: Tracing within Tomcat indicates that the Content-Disposition header is not set. I don't know for certain that it's not being received by the browser, but AFAIK the browser is connecting directly to Tomcat. This seems like an odd browser-side behavior.
The issue had to do with presence of the following headers in the response:
Cache-Control: no-cache
Pragma: no-cache
These were being sent by Tomcat because the page was being protected by a security constraint (configured in conf/web.xml). These headers caused IE7 to act just like a 'Content-Disposition: attachment' header was present.
My solution was to have the customer add the following configuration to Tomcat's conf/context.xml:
<Valve className="org.apache.catalina.authenticator.BasicAuthenticator" securePagesWithPragma="false" />
This replaces the headers with:
Cache-Control: private
...which should still fulfill the goal of preventing proxies from caching the page, while working around IE's issues. This was based on the solution found here:
http://daveharris.wordpress.com/2007/07/09/how-to-configure-cache-control-in-tomcat/
However, that very-similar solution suppressed the headers entirely. Details of these attributes can be found in Tomcat docs here:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes
You should be able to log the outgoing HTTP responses on the server side before encryption, use the null cypher, or provide the RSA keys to wireshark and look at the headers from a packet capture.
Related
I have a GWT Web App (which requires a login) that calls a method on the Servlet (running in Tomcat) to generate a PDF file. The Servlet returns a URL to the file and opens the PDF in an iFrame.
Frame frame = new Frame(reportUrl);
frame.show();
Upon closing the frame (or browser), a request is made to delete the file that was generated server side. Now here is where the problem lies. If I log out of the web application, and open a new tab in IE, it shows the URL in the history that was used to display the PDF. Ideally this file is no longer accessible since it has been deleted on the server, and the user is no longer logged in, however the PDF still displays in the new tab. I assume this is because the PDF file is being cached.
I am unable to reproduce this behavior in Chrome, so I assume the file either isn't being cached in Chrome, or Chrome just handles things a little differently. Long story short, how do I make sure the file/url is no longer accessible once the user logs out of the web app?
Theoretically this is impossible, as you can't remotely clear the client-side cache. Also the user may have used wget or whatever to download the file so you can't assume information will be 100% inaccessible after the session has expired.
That being said, caching hints in the HTTP response headers can to some extent steer what a (well-behaved) client caches. As always implementation differs accross browsers. You can set HTTP headers either from your servlet directly in Java, or you can add them for instance from Apache HTTPD specifying cache headers for instance for all PDF downloads.
There are many resources on cache headers in HTTP, here's a good one: http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
I've also seen that HTTPS connections cause IE to be much stricter in what it caches, not sure if that is relevant/an option for you.
As per my understanding files are cached by the browser by default. Developers don't have to set specific
headers to enable the caching of these files. Right?
If yes, how come browser know that it has to enable caching for specific types of files only not for servlet/jsp calls. For example :- if i make call to same servlet
request goes to server side and fresh page is served (not the browser cached paged).
I have few same js and css files and i used to load from different jsps.
If already css and js loaded, we need to not load files again.
But those files are reloading. And giving 200 Success code in firebug console.
it should give 302 success code
i can hit the url directly. I dont want to call js and css dynamically.
load the jsp content
css and js loading done through relative path. i couldnt copy the code. Because it is not allowing here
If any additional information require, pls update
Assuming that you are referencing the CSS and JS files from your JSPs as static references in <script> and <link> tags, you can avoid the scenario where the browser is provided with these files on every request by setting HTTP headers when you first serve them.
Without setting appropriate expiration times or "freshness" guarantees for resources, browsers will typically end up issuing for a fresh copy of the resource every time, even though the resource may be present in the browse cache. Note, that if the browser cache is disabled, then you cannot, as a web-programmer do anything about the browser's behavior, unless you get your users to enable the browser cache; until then, the browser will request for fresh copies of resources every single time. These requests may be served by a proxy cache, but it is not necessary that such a cache exist.
Setting resource expiration times or freshness guarantees in Java web applications can be accomplished by either of the following:
Configuring the HTTP server, or the Web Application server (if that is possible) to set Expires and Cache-Control headers in the HTTP responses generated for the CSS and JS files or mimetypes. Configuration changes that ought to be done would vary from server to server and are too expansive to list here.
Writing a Servlet filter for your web application that will intercept all responses for URLs ending with *.js and *.css and add HTTP Expires and Cache-Control headers to the responses. This option is less preferable especially if you wish to have the same amount of configurability that is afforded by web and application servers; you will need to provide any configuration options via init parameters for the filter in your web.xml file. Also, changes to the configuration will require a restart of the application containing the filter.
If you need to understand the values to be specified for the Expires and Cache-Control headers, then I would recommend that you read the "Caching Tutorial for Web Authors and Webmasters", which provides details on how to use the Expires and Cache-Control headers and how they affect caching behavior.
Suggested values for the expiration times specified in the Expires header or the max-age value in the Cache-Control header, range from a few minutes to a few hours, depending on how often you change the site content. You must also avoid specifying Cache-Control headers with no-cache and no-store values, for they would often end up issuing requests for the same resource on the next attempt.
Recently we implemented OWASP security solutions with OWASP.jar. After this, our application was working fine in IE 7 and Firefox 3.5. But the application is not working in Safari 4.0.5 or 5.0.
The console shows this message:
"Possible CSRF Threat detected ! redirecting to login page.."
I am unable to log into the application. Even the request itself is not taking.
If you have any ideas, please suggest them to me. Is there anything I need to do with the settings of the Safari browser?
We are using Java for development.
Assuming that you are referring to OWASP CSRFGuard 2.x here (there is no library/framework called OWASP), the message referred to, is displayed when the incoming CSRF token is absent or different from the one expected (which is stored in the HttpSession object). The token itself is managed via a session cookie on the client side, having a default name of OWASP_CSRFTOKEN.
It would be a good thing to check for the following:
Are cookies enabled in Safari?
Is the browser transmitting the CSRF token cookie on every request (after it has been initially set) to the server?
Has the server conveyed the session cookie containing the CSRF token to the client? And, is the server generating a CSRF token (utilizing a SHA1PRNG provider by default) when the first request is submitted by the client to the server? This is less likely to be a problem, given that there are no problems with MSIE and FF.
I have a java applet that needs to do http requests to the server. A quick experiment showed that the session id cookies from the browser is not sent along, so i'll have to set it manually.
Currently, I see 2 possible solutions:
somehow get hold of the cookie data from within the applet
pass the cookie information into the applet's contructor via javascript
I'd prefer the first solution, but i wasn't able to find a working solution for that. all information i found (mostly netscape.javascript.JSObject) were outdated (my 1.5 VM does not have this class)
Any great ideas or resources i have not yet found?
Are you sure your JVM doesn't contain this class? You should look in $JAVA_HOME/lib/plugin.jar. I found it in my 1.5.0_14 installation.
If you are generating the page dynamically, you don't necessarily need to use JavaScript to communicate the session ID. As long as you know it server-side, you can place it into an applet parameter tag in the generated HTML which contains the <applet> tag.
Nowadays all browsers are supporting httponly cookies.If cookies are consciously set in server as 'httponly' in appropriate response headers,applets may not be able to access it.