I am trying to upgrade Tomcat 5.5 + JDK 5 to Tomcat 8.5.x + JDK 1.7
The application that is deployed on this server is a legacy application which uses FTL (2.3.4) + DWR(2.0.3) + Spring (2.5.5) frameworks
When deployed on Tomcat 8.5.6 + JDK 7 I am getting errors on few actions which perform POST request from the application.
Most of these actions are DWR calls for filtering/manipulation of data displayed on the screen.
There is a popup message "Session Error" displayed on screen.
On front end profiling I found that the complete error is a SecurityException which results into SessionError.
Session Error - SecurityException
When debugged on server side I found out that the request was being treated as a CSRF attack and hence this exception was thrown.
DWR checks for the HTTP session ID in the body of the POST request to validate the request against CSRF possibility.
So in front end debugging I found that the request is not sending the httpSessionId in the POST body.
Request header and body are as shown here.
I have tried disabling the crossDomainSessionSecurity parameter in DWR servlet initialization.
It works fine after that, but I cannot go ahead with the security risk it poses in the production environment.
Due to this issue I am not able to go ahead with the Tomcat migration.
Please suggest how can I resolve this issue?
I was checking for some new features in Tomcat 8.
I read that from Tomcat 6 onwards Tomcat allows only HTTP requests by default.
Which means that the useHttpOnly flag is true by default.
This causes the javascript requests to fail.
In the deployment I tried by setting the useHttpOnly=”false” and the application works fine after that.
I will do more tests on my side, so for now we can consider this issue to be resolved.
Related
I have a website (Liferay portal 6.1 and Tomcat 7.0) which is having HTTP and HTTPS URL like below.
https://stackoverflow.com/questions/ask
https://stackoverflow.com/profile
I follow below steps and I am getting Forbidden error:
I fill some form details in 2nd URL.
Before submitting that form I open 1st URL in a new tab.
Then if I come back to 1st URL and do a submit then I found a forbidden error.
I checked JSESSIONID at both tabs, Ids are same. What may be the issue? Any idea guys?
It's not worth investing time in making http/https mixed mode work (in my opinion). Bite the bullet and just go https always. Even if you'd fix this issue now, chances are that you'll run into more issues later, eating up more of your time. And when you run into other issues, they're highly likely security sensitive.
Do yourself a favor - unconditionally redirect ALL http traffic to https. It's 2016, there's nothing unusual with this any more.
Edit after your comment: Do this especially if it's an old system (by the way, this was obvious when you mentioned Liferay 6.1. Assuming you're using CE, it's long out of updates): Configure the use of https anywhere you can easily get your hands on. Unconditionally add the HSTS header to take care of the rest. No need to touch any ancient logic. E.g. set
web.server.protocol=https
in your portal-ext.properties. Add the HSTS header to your Apache httpd unconditionally (assuming you have Apache httpd, otherwise use this Liferay App from yours truly).
All of a sudden, when i run tomcat from within intellij, the output console is constantly bombarded with messages.
(very) short video showing this:
http://screencast.com/t/ddBhIh3UZiA
The messages constantly output is:
16:05:31,157 WARN http-nio-8222-exec-1 servlet.PageNotFound:198 - Request method 'HEAD' not supported
16:05:31,158 WARN http-nio-8222-exec-2 servlet.PageNotFound:1120 - No mapping found for HTTP request with URI [/] in DispatcherServlet with name 'dispatcher'
I am using Spring 4.1 and tomcat 8.
Java 8 and Windows 8.1
This phenomenon didnt use to happen before and it suddently started occuring. What is going on?
I'm having the exact same problem. If you have your Tomcat run configuration set to open a browser on launch, IntelliJ will try to ping the website to ensure it's up prior to opening the browser. I believe it's doing HEAD requests and since your site isn't set to answer / HEAD requests, you get the error.
Unchecking the "After launch" checkbox under "Open browser" in the server tab of the run configuration fixed it for me.
As for getting JetBrains to fix this, I'm not sure what to do about it. I did just upgrade to 14.0.3 so that might be the cause...
Solved by JetBrains in this ticket, and if you want you can change a Jar to avoid the regression.
https://youtrack.jetbrains.com/issue/IDEA-135196
It seems your client is using HEAD has the request method. It is similar to GET but it says to the server that it must not return message-body in the response.
Either check your pages or client for HEAD requests or accept HEAD as RequestMethod like this:
#RequestMapping(method = {RequestMethod.GET, RequestMethod.HEAD})
I have a Grails application that is running in Tomcat 7 under IIS 7, using the Jakarta Isapi Tomcat connector version 1.2.30 and I'm having trouble getting the error handling to behave how I'd like. The Tomcat connector is configured in uriworkermap.properties to forward all requests below the application's URL to Tomcat:
/OrderSubmission/* = worker1
The Grails application has its own custom error pages which work fine when the application is running on a development machine without IIS / the Tomcat connector, but when on the server, if custom error pages are switched on in IIS, these always override the ones in the Grails application. This means that where I have a specific page to handle a certain exception type, e.g. in UrlMappings.groovy:
"500"(controller: 'error', action: 'itemNotFound', exception: ItemNotFoundException)
...I'm instead seeing the static 500 error page that I've pointed IIS at.
If I instead turn on detailed errors in IIS I get the correct error pages through from my Grails application - however, if a request is made for a URL outside of the application's context, I then see the detailed IIS 404 page, which is unacceptable. If I change the Tomcat connector's uriworkermap.properties to include everything from the root downwards then I instead see a default Tomcat 404 error page. I've tried getting the Tomcat connector to default to custom pages by setting the error_page option in isapi_redirect.properties to point to my IIS static custom pages like so:
error_page=/%d.htm
...but this doesn't work, and I can't find any example of using this setting anywhere.
What I need to happen is for the custom Grails error pages to be shown - unless the URL being requested is outside the application or the application is down, at which point I need custom static error pages to be shown.
Has anyone managed to achieve this?
TIA
I ended up making my error page controller methods return a status of 200 (OK), unless dealing with an AJAX request:
class ErrorController {
def pageNotFound() {
if (!request.xhr){
response.status = 200
}
}
}
IIS is set to 'Custom error pages'.
This prevents IIS stepping in and providing the custom static pages that I provide, unless the requested URL is outside the scope of the Grails application.
The error status is retained for AJAX requests in order to allow the caller to properly deal with the result.
I'm unsure whether it's satisfactory practice to return 200 from the application on error, particularly with regard to search engines - however it seems that even without this change, when an error occurs and the response is ultimately returned to the browser from IIS it has a status of 200, according to Fiddler.
I have written a RIA using flex for the front-end and Java servlet for the back end which actually makes calls to a web-service to do some processing.
The welcome page is a html page which is served from the web-logic 8.1 server that the app is hosted on. The welcome page loads and the flash content loads. Even a 'xml' file containing some configuration properties gets loaded from the server (through URL Request).
Now when I click a button on the page, it would authenticate the user, by sending the data to the servlet.
Here's the problem... The servlet doesn't get invoked and the URL Request (for the servlet with appropriate parameters) returns a 500: Internal Server Error page.
The same code is working perfectly when I deploy it on my local machine using tomcat as a server. And I have also checked umpteen times if the host URL is correct when being deployed on the web-logic server. Even checked the URL when the request is being made, in firefox, using firebug, and all seems to be fine, except that the response is '500: Internal Server Error'.
Please help. Thanks in Advance.
OK, the welcome page loads, and an XML file loads from the webserver, but the servlet can't be invoked.
Is the servlet initialising correctly, and waiting to be called?
Does anything need to be changed in the web.xml file that hasn't been?
Without any more information, it sounds like a misconfigured servlet and/or app server. Check your logs to see if there's any more information there.
I have a Tomcat 6 webserver running my application and I am seeing some very strange redirect behaviour.
I expect to access my application at the internal URL http://appteam.testdomain.co.uk/test and that this will return a 302 redirect to http://appteam.testdomain.co.uk/test/ which then serves up index.html, the front page of the application.
However, a GET for http://appteam.testdomain.co.uk/test currently returns a 302 to http://appteam.testdomain.co.ukteam.testdomain.co.uk/test/
How would I debug this weird redirect and what Tomcat config could possibly be causing this behaviour?
EDIT
For clarity the strangeness here is that a request for
http://appteam.testdomain.co.uk/test
is being redirected to
http://appteam.testdomain.co.ukteam.testdomain.co.uk/test/
Note the mangled domain.
EDIT2
#Sean - I am not doing the redirect myself. Something deep within Tomcat seems to be handling this for me. Let me know which parts of the various Tomcat XML files would help to diagnose this and I will post them.
I have worked out the answer and it is very specific to the way my app is deployed. Tomcat sits behind an NGINX proxy which forwards almost all traffic to Tomcat. The Proxy is used to handle some URLs differently. It turns out that Tomcat is returning a correct 302 to
http://appteam.testdomain.co.uk/test/
but the NGINX proxy is mangling this into
http://appteam.testdomain.co.ukteam.testdomain.co.uk/test/
This behaviour seems not to be an error. Jetty also sends a 302 redirect if the request points to a directory without the trailing slash.
The Apache URL Rewriting Guide contains a section about the Trailing Slash Problem.