I recently built a simple web-app deployed over Tomcat. The app uses pretty standard session based security where a user who has logged in is given a session.
Sessions work fine in Firefox and Chrome, but require the use of jsessionid in the URL for IE (tested 7 & 8), set to medium privacy. In IE 8, I tried to override cookie handling, setting "Allow all 3rd party cookies" and "Allow all session cookies"- no dice. However, when I run Tomcat on my local machine, IE accepts the cookie, and sessions work just fine.
And now, for the HTTP headers.
From Chrome, a logged in user gets a session
GET http://devl:8080/testing/ HTTP/1.1
Host: devl:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1036 Safari/532.5
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
P3P: CP="NON CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT STA"
Set-Cookie: JSESSIONID=9280023BCE2046F32B13C89130CBC397; Path=/testing
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2450
Date: Fri, 26 Mar 2010 14:14:40 GMT
GET http://devl:8080/testing/logout HTTP/1.1
Host: devl:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1036 Safari/532.5
Referer: http://devl:8080/testing/
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=9280023BCE2046F32B13C89130CBC397
...
From IE 8, with standard medium level security and privacy-
GET http://devl:8080/testing/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; Tablet PC 2.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: devl:8080
Connection: Keep-Alive
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
P3P: CP="NON CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT STA"
Set-Cookie: JSESSIONID=192999F922D6E9C868314452726764BA; Path=/testing
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2450
Date: Fri, 26 Mar 2010 14:32:34 GMT
GET http://devl:8080/testing/logout HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://devl:8080/testing/;jsessionid=6371A83EFE39A46997544F9146AA5CEA
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; Tablet PC 2.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: devl:8080
...
I thought it might be P3P, but on adding a compact policy, nothing changes. This is the standard Tomcat session, so I'm really surprised I haven't been able to find other people with the same problem so far. Anyone have any ideas?
EDIT 4/3/2010 -
Sorry if I didn't make this clear- I've tried from multiple other instances of IE - co-workers down the hall, etc.
EDIT 4/3/2010 -
I've also tried turning on prompting for all cookies, but I don't get a prompt. Setting the domain in the "Set-Cookie" header using Fiddler didn't make a difference, either.
I ran into this exact problem, dug around for a while, and found this:
http://forums.iis.net/p/1147938/1879164.aspx
which says that domain names that have underscores in them cause problems with Windows Server, tomcat and IE
not sure if this fixes your problem (and at this point, you probably don't care) but maybe the next person who comes along can gain some value from it.
Problem: IE8 refused to accept cookies on a site I had built, but Firefox and IE7 worked just fine and had done so for ages - this was stable code.
Solution (for me): My server is in a different time zone to the client machine. The STUPID, IDIOTIC IE8 tries to be clever and refuses to accept cookies (stored in the local client machine) with a 20 minute life. My PHP code was straight from the text book, thus:
setcookie($name,$value,time()+1200);
But it works fine if I change it to, for example -
setcookie($name,$value,time()+120000);
This still leaves me with the problem of making the cookie die after 20 minutes, but at least my users can now use my website with IE8. I pass on this information in case it may help someone else.
Have you checked that the server time is correct?
I have had similar problems recently with IE not accepting cookies properly. After a lot of head scratching it turned out to be because the time difference between the server and client machines was so big that IE refused to accept the cookie. This was in Apache however.
Try using the standard HTTP port (80). I've read about issues with port numbers in URLs regarding privacy/security in IE more than once but can't seem to find relevant links at this time.
I agree with Lexicore - the cookie protocol from the web server looks right, so there's something with IE. It would be easier to figure out how to address the issue if we understood better why IE is rejecting the cookie. Alternatively, ask a friend to hit the site for you in IE to help confirm its a server issue not a browser instance issue.
Here is some things to check to help debug with IE and cookies - unfortunately, there's a mess of options to check. Sorry if some of these items seem basic - I just don't wnat to make any assumptions. I'm following along in IE 8.0 for this.
First, browse to the target site (http://devl:8080/testing/) in IE. Then:
Confirm what zone IE classifies 'http://devl:8080/testing/'. (This could explain why its works with Tomcat on your local machine.) The zone is displayed in the bottom bar of the browser and it most likely says "Internet". If it instead says "Local intranet", "Trusted Site", or "Restricted Site", this may be part of the problem and you should update your question or figure out why it isn't classified as Internet.
Double-click on the zone indicator in the bottom bar (presumably "Internet") to open the Security dialog. Is the Security Level for Internet set to Medium-high? If it isn't, this could be part of the problem and you should probably reset it back to match your users.
Select the "Internet" zone and then click the "Custom level ..." button to open the Security Settings dialog. Confirm the "Userdata persistence" option is set to "Enable". The "Userdata persistence" option is in the bottom 1/4 of the list of options in the "Miscenllaneous" section (near the bottom of the section just above the next section "Scripting").
Click OK on each dialog to close both of them.
On the menubar (enable it if it is not enabled), click "Tools" > "Internet Options". Select the "Privacy" tab. I know you mentioned you tried some things here, but those changes may not affect your site if your site is not in the Internet zone or if your site in the "Per Site Privacy Actions" exception list, so its best to just confirm.
Is the privacy setting in the Privacy tab set to Medium? If not, you may want to reset to default.
Click the "Sites" button to open the Per Site Privacy Actions dialog. Is your dev1 site listed? If so, remove it. Click OK to dismiss the dialog. Alternatively, you could force your dev1 site to always Allow cookies.
Click the "Advanced" button. Is "Override automatic cookie handling checked? If so, you might want to uncheck it to match your users. Alternatively, try checking it and checking "Always allow session cookies."
Click OK on each dialog to close both of them.
Confirm the browser is still at target site ('http://devl:8080/testing/'). Click "View" > "Webpage Privacy Policy..." to view the Privacy Report dialog. Does the list include "http://dev1:8080/testing/"? Does the Cookie column indicate "Accepted" for "http://dev1:8080/testing/"?
Select "http://dev1:8080/testing/" from the list. Click Summary to see the Privacy Policy. If set one for the your site, you should see it here. Otherwise, you should get a message that a privacy policy was not found. Look at the bottom of the dialog to see how the site is set to use cookies (compare, always allow, or never allow).
Hope this helps or gives you some ideas to pursue.
Ref:
http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx
http://www.practicalmachinist.com/vb/general/how-manage-cookies-internet-explorer-181641/
http://support.microsoft.com/kb/283185
This forum concerning P3P seems relevant.
Also have you considered setting your domain and expiration date for the session cookie?
This has clearly nothing to do with Tomcat, since the cookie is being set - just not accepted by the IE. This must be security issue in IE then.
Maybe this MS article would help to tune it.
What security zone is the dev1 site part of? IE handles cookies and lots of other security differently depending on which zone (and how the zone is configured).
Try setting the dev1 site to explicitly be part of the Trusted Sites for example and see what happens.
Zones:
Internet
Local Intranet
Trusted Sites
Restricted Sites
Also, does the cookie have to be restricted to the /testing path? Try setting it for / and see if that makes a difference.
I would try using the fully qualified hostname of the server. MSIE treats hostname without domains as being in the "Local intranet" and handles security differently.
Specifically, instead of:
http://devl:8080/testing/
Try using something like:
http://devl.mydomain.com:8080/testing/
It seems from what you're saying that you've only seen this issue in IE and only using computers in your office. Is there any sort of "security suite" installed by IT on all office computers, and if so, can you temporarily disable it? Oftentimes, these types of applications hook into IE and muck with its HTTP stack. If you do have software like that installed, do you have a "clean" installation or non-company computer you can test with?
The time on our servers were off by 14 minutes (and in the correct time zone EST).
Once we set the time on the server to the correct time cookies starting working again.
Ed
Related
NOTE: This is not a duplicate question. I'm aware of concrete problems that looked identical to mine and were solved by adding some data to the header requests. This is not the case, I've tried all the solutions and none works. Tried: this question and this one, nothing seems to work.
I'm trying to read contents of a website using Java. The url is URL to fetch. There's no authentication involved, and no forms are filled before. I can open that url in a cookie-free session and it still works with browser. I can even fetch it with Selenium, but HttpClient keeps refusing to load the URL.
The problem has nothing to do with certificates, right now I'm using a working "allow-all" certificate manager, so that's not the issue.
I've inspected my browser sent headers, nothing special:
Host: www.hipercor.es
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
As I said, I've already tried configuring the user agent to "fake" being Firefox.
Just to give some background, I'm building a enhanced version of crawler4j, my idea is to build a web scraper, and I found this issue testing random shops I knew are currently being crawled in bussiness environment by other scrapers.
Note that HeadRequest also fail.
The errors are either
java.net.SocketException: Connection reset
or
java.net.SocketTimeoutException: Read timed out
Please, note that browser loads it perfectly, as well as using Selenium Drivers to load the page (although it is slow as hell in that case)
I created cookies with HTTPOnly flag in Safari browser using java
See Response header below.
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer:http://anil.mlbextrabases.com/SafariIssue/
User-Agent:Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Query String Parametersview URL encoded
userName:servlet
userPass:servlet
flagRequired:true
Response Headersview source
Content-Length:331
Content-Type:text/html;charset=ISO-8859-1
Date:Wed, 08 Aug 2018 09:23:45 GMT
Server:Apache-Coyote/1.1
Set-Cookie:userInfo="username: servletpassword: servlet"; Version=1; Comment="creating cookie"; Domain=anil.mlbextrabases.com; Max-Age=31536000; Expires=Thu, 08-Aug-2019 09:23:45 GMT; Path=";Path=/;HttpOnly;", JSESSIONID=076942707A8D62AD1296102A1593F664; Path=/SafariIssue; HttpOnly
Strict-Transport-Security:max-age=7776000; includeSubdomains
But cookies are not passed in subsequent requests in safari browser. While passing in other browsers like Chrome, Firefox, IE, Edge
When i removed HTTPOnly flag cookies are passing good in Safari browser as well.
I did a lot of R&D over developer communities. But it not helped.
HTTPOnly cookies by definition are created to NOT allow access from javascript.
This is a security control to make sure that a hacker can not exploit your software by extracting valid cookie values (like session IDs)
HttpOnly is a flag the website can specify about a cookie. In other words, the webserver tells your browser “Hey, here is a cookie, and you should treat is as HttpOnly”.
An HttpOnly Cookie is not accessible by the JavaScript. Only the browser knows about it, and it doesn’t give it to the JavaScript code in the page. At first, it might sound like a limitation, and it is. However, the goal of that is that we cannot trust the JavaScript code. An attacker may use JavaScript to steal our authentication token stored in a cookie, and then access the website with our account. With HttpOnly cookies, this is not possible. This makes XSS attacks (the one we just described) harder to perform.
It is a recognized best practice to share any authentication data only with HttpOnly cookies. Using a standard cookie for authentication is a known vulnerability we should avoid in any case.
https://www.ictshore.com/ict-basics/httponly-cookie/
I'm trying to create a simple REST service to serve audio files (with seek support).
I'm using this example which is based on Jersey:
https://github.com/aruld/jersey-streaming/tree/jersey2
This is a quite simple example, it listens to GET and HEAD requests used by the browsers, look for the Range header and respond with 206 plus the archive slice requested (with byte ranges).
The catch here is that I'm re-writing this on spark java (a tiny framework with an embedded jetty server).
Every thing seems to be OK. The browser sends the GET and the server crates the response accordingly... though the player never loads nor plays anything. The request is made and the response header is perfect:
Request:
Host: localhost:4567
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=0-
Connection: keep-alive
Response:
Accept-Ranges: bytes
Content-Length: 1048577
Content-Range: bytes 0-1048576/5563904
Content-Type: audio/mp3
Date: Sat, 20 Aug 2016 05:41:23 GMT
Last-Modified: Sat Aug 20 01:12:37 BRT 2016
Server: Jetty(9.3.6.v20151106)
sasd
One thing I noticed is that seems the transfer for this request never ends. When I close the server, the transfer ends at 0,03KB (always).
My proof of concept app code:
http://pastebin.com/xjkLne7E
Found an answer!
I did some more research and found that it is a Spark feature to be implemented:
https://github.com/perwendel/spark/issues/397
User tchoulihan already tried to implement such feature with success here:
https://github.com/tchoulihan/torrenttunes-client
Here is a sample of the spark get request that handles the upload:
https://github.com/tchoulihan/torrenttunes-client/blob/master/src/main/java/com/torrenttunes/client/webservice/Platform.java#L555
I can't paste a blob here since GPLv3 would clash with cc-wiki license. Hes work is inspired on the same resource I first found. Based on that I have coded a version of my own that works on android, mozilla and chrome.
TL;DR The problem was that mozilla doesn't understand 206 request properly and I wasn't closing and flushing the ByteOutputStream. Also I tried to use the StreamingOutput from JAX as a response instead of sending a simple raw http response.
In below code sample am getting the http method get is used as reQuest now want to know what are all the http methods my tomcat server support.Please help to find this.
GET / HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.6 (X11; I; Linux 2.2.6-15apmac ppc)
Host: zink.demon.co.uk:1126
Accept: image/gif, */*
There is no way to know this unless you ask the server which methods it supports.
Usually this is done with the OPTIONS HTTP method, but not all web servers support it. Also, it applies to a specific URL, not the whole server.
Can someone please help me with a HTTP caching question?
I thought that if I set the "Expires" and "Cache-Control:max-age" request headers, then a browser wouldn't make a GET request until after the max-age had passed?
My server is seeing lots of conditional GET requests, and it replies with a 304. However, I'd like to eliminate these conditional GETs if possible and have the browser only ask for a resource once it thinks it has expired.
Here's the details I get from the developer tools in Chrome:
Request URL:http://localhost:8080/img/branding.gif
Request Method:GET
Status Code:304 Not Modified
Request Headers:
Cache-Control:max-age=0
If-Modified-Since:Thu, 22 Jul 2010 10:54:34 GMT
Referer:http://localhost:8080/
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4
Response Headers:
Cache-Control:max-age=2246400, s-maxage=0
Connection:Keep-Alive
Content-Location:/img/branding.gif
Content-Type:image/gif
Date:Fri, 23 Jul 2010 15:06:10 GMT
Expires:Fri, 07 Jan 2011 15:06:10 GMT
Keep-Alive:timeout=15, max=100
Last-Modified:Thu, 22 Jul 2010 10:54:34 GMT
Pragma:cache
Server:Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)
I set the cache headers in a filter in my Java code. The code is running on Oracle's OC4J.
Also, I want to run this over HTTPS. Will using the same headers work for HTTPS too?
Thanks in advance.
Remove "Last-Modified" header. Some browsers always send conditional GET if that header exists.
Could it be the s-maxage=0? Can you lose that, or set it the same as the maxage?
The conditional gets could be coming from proxies, or from browsers that have somehow decided to act like proxies. Seems unlikely, i admit.