It appears that when a Set-Cookie: HTTP header is sent from the server to the Ant Client during a 302 Moved Temporarily response to a Get core task (or a Post optional task) the cookie is not stored within the Ant client. This violates RFC-2109 (sec 4.2.1). The result is that certain security mechanisms, such as SAML, that rely on HTTP redirection to establish a security context fail. Example: <target name="restart" depends="init"> <get src="https://insecure-bank.org/saml/login?Target=/restart.jsp" dest="results.html" username="1214"; password="secret"/> </target> If /saml/login establishes the security context and then sends a redirect response (status code 302) that contains a Set-Cookie and the Location header (/restart.jsp). The Set-Cookie is ignored by Ant and the security context is lost.
The get task in Ant was never built to be a "client" (its not a browser) - it just implements the HTTP protocol.
(In reply to comment #1) > The get task in Ant was never built to be a "client" (its not a browser) - it > just implements the HTTP protocol. Neither is it a client in that it does not pay us for our services [grin]. However, when it is performing a "get" or "post" task, it does perform the role of client. It certainly is not the server in that instance. The point is that it appears, on my system anyway, to break RFC-2109. This will cause problems as more environments move toward a federated security model such as SAML. I want to restart a process on my server after I upload new code. The restart is protected using SAML, which requires conformance to the HTTP protocol standard including proper handling of cookies as defined in RFC-2109.
The GET task in ant uses the standard java interfaces on HTTP. (URL and HttpURLConnection) according to Sun, cookie management is taken care of. (http://forum.java.sun.com/thread.jspa?threadID=452352&tstart=195) When testing against an own server I Can see that firefox returns the cookie on the 302 redirect and the sun implementation doesn't. Also, please note cookies are not part of the HTTP/1.1 specification (RFC2616), therefore I'll mark this report as an enhancement request.
I'm using JMeter to test Moodle (open source PHP app) - it gives a 302 redirect when you successfully post to the login page, so this bug destroys the login session. It's never a problem for any web browsers. I'm working around it by not following the redirect, instead using a separate request to go to the redirect page.