Wesley Acheson wrote:
On Mon, Mar 30, 2015 at 10:24 AM, Aurélien Terrestris <aterrest...@gmail.com
wrote:
If you write a Valve (which would be Tomcat-specific, and not work
under other servlet containers), you could change the way Tomcat reads
session identifiers from the request (and use a request parameter
instead of a path parameter).
Maybe could you also have a look on Filters since they're made for
modifying the request before it reaches the servlet (or modifying the
response after it leaves the servlet) :
http://www.oracle.com/technetwork/java/filters-137243.html
Yes I know how filters work. However their within the lifecycle of the
webapp. A filter can't associate a session with a request :(
A bit of thinking out of the box, maybe futile but one never knows.
The basic reason why "it doesn't work" now, is because these cookies are somehow
third-party cookies. Of course I don't know your application, but isn't there some way in
which this can be changed, to make these into "first-party cookies" ?
There maybe you could use a servlet filter to catch/set the cookie headers, and if needed
proxy something to the third-party server involved ?
To elaborate : if the main application is sending third-party cookies to the browser, then
these are "Set-Cookie" headers in the responses, said cookies having a domain part that is
not the server of the application. A servlet filter could rewrite these cookie headers,
and change the domain part to be the main server. Then they would be accepted by the browser.
Similarly, since the cookies would then be re-sent to the main server by the browser as
"Cookie" headers, they could be caught by the same servlet filter in the requests, and
whatever needs to happen with them, done then. (Having the servlet filter recognise such
requests, and possibly proxying them to the third-party server).
Complicated, but maybe less so (and less intrusive) than changing the whole
application logic.
Further along the same line of thought, one could put a front-end Apache httpd server in
front of Tomcat, and do all this kind of stuff there, where there are already numerous
standard tools to do such things as URL rewriting, Cookie rewriting, conditional proxying
etc., in a generally simpler way than under a Java servlet engine like Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
