I manage a few Tomcat 9 applications that are run on a remote server that also use IIS 8.5. Each site has three environments (DEV, TEST, and PROD). All of the environments are the same but on different servers. Their databases (Oracle DB) are also on separate remote servers. I do not use any other third party frameworks for the sites (such as Maven or Gradle).
One of my applications had an issue where an attacker could access the web.xml through a Multiple Directory Traversal Vulnerability. Some brief information can be found here: https://www.securityfocus.com/bid/63052/exploit
However, I discovered on the DEV and TEST (I thought PROD as well) that the filter we put in place was actually causing the site to not work correctly. You'd put in your user and password and click login and nothing would happen. I seemed to have fixed it on the DEV and TEST environment by fixing the regular expression that my code was testing the URI against. Code:
final String REGEX_INCLUDED = ".*\\/WEB-INF\\/web.xml.jsf.*";
...
if (Pattern.matches(REGEX_INCLUDED, URI)) {
log.debug("SecurityFilter redirect");
resp.sendRedirect("/errors/403.html"); // /login.jsf OR /index.html
} else
chain.doFilter(request, response);
I deployed the new war onto PROD, entered my user and password and it would load. The site redirects to the homepage after login, BUT it doesn't actually load if that makes sense. The response is a generic 502 error (shown below) but the URL does, in fact, say /home.jsp where it should respond with the homepage.
502 Error
I've checked the catalina log and I've not found a stack trace or any sign of an error being output. No other logs are useful either in showing what the issue is. I've tried just clearing my cache and retrying, using a different browser, restarting the tomcat service, restarting the site in IIS and nothing.
If there is something I'm missing that you wish to see let me know. BTW, I've tried removing the filter that blocks access to the web.xml just to make sure it wasn't the issue and both with and without the filter, it results in the 502 error.
Thanks in advance for any help.
Answering my own question: I had looked around everywhere and only after posting I found a related post:
502 proxy error on deployment
Their answer helped. The difference between my PROD environment and my DEV/TEST environments is that PROD is on a Proxy. I went to IIS on the server and found the server farm that the site used. I then clicked on the Proxy option and changed my timeout from 30 seconds to 60 seconds. Looks like my proxy was timing out. Hope this helps someone in the future.
Related
I created spring application implemented with oauth2.0 (authentication_code flow) and deployed into Azure App service. When I run it in my local machine its working properly and getting oauth token properly. But I deployed the same code in Azure App, its not working it showing ******.com redirected you too many times.
When I trace the traffic in "Network Sniffer", there is no cookie information in the response.
For reference i attached error screenshots.
Per my knowledge, ******.com redirected you too many times error is different variation of error ERR_TOO_MANY_REDIRECTS(also known as a redirect loop) in Google Chrome browser.
You could refer to below recommendations and things to check to fix the error.
1.Delete cache and cookies on that specific site
Cookies can sometimes contain faulty data in which could cause the ERR_TOO_MANY_REDIRECTS error.Due to the fact that cookies retain your “logged in” status on sites and other settings, we recommend simply deleting the cookie(s) on the site that is having the problem. This way you won’t impact any of your other sessions or websites that you frequently visit.
2.Determine nature of redirect loop
The free online Redirect Checker tool can help provide some further analysis into what might be going on. This could also be done via cURL.
3.Check your extensions by typing chrome://extensions
Disable each of your extensions one by one while checking and refreshing your page, if the page starts working while a particular extension is disabled, that extension is faulty and you should delete it.
4.Check Your HTTPS Settings
If you have an SSL certificate on your domain host, you may deactivate it.
Hope it helps you.
Sorry if this question was asked before, if it was, I didn't find it.
I'm using GlassFish 4.
When I need to redeploy an application (for fixing a bug for exemple), its URL will return temporarily a 404 NOT FOUND error until the application is fully redeployed.
My question is: do you know a way to redirect the URL to another application or a web page ("Application not available for the moment...") during the time the URL is inaccessible?
I heard of load balancer but it's between 2 servers (which I don't have).
Thank you.
You can use rolling updates to update an application without any downtime, by using the :version suffix. For full information on how to do it, see the blog post at http://blog.payara.fish/payara-server-rolling-upgrades.
I'm trying to upgrade from Tomcat 5.5 to Tomcat 7, and almost everything is working -- I just have some cookies that are getting through on Tomcat 5.5, but disappearing on Tomcat 7. That is, Firebug confirms that the cookies are being sent in both cases, but on Tomcat 5.5 they show up in a request.getCookies() call, and in Tomcat 7 they don't. Some cookies still show up (JSESSIONID, for example), but a couple are missing.
This is the same application running on the same server, port, etc, I just shutdown Tomcat 5.5, startup 7, and the cookies no longer get through.
If it's relevant, both Tomcat instances are behind an Apache proxy running on a different server. It doesn't seem like it should be relevant, though, since Apache is clearly able to pass the cookies to Tomcat 5.5.
My guess is it's a security feature of some sort, though I haven't been able to figure out what it would be. The missing cookies are for domain .domain.org, while the cookies that are getting through (like JSESSIONID) are for host subdomain.domain.org (bolded text is just an example, obviously).
I tried setting useHttpOnly to false and crossContext to true in the context, in case it had something to do with one of those, but it didn't help. Besides those two settings, are there any other new features in Tomcat 7 (or Tomcat 6, for that matter) that could lead to it leaving out cookies? And if so, is there a handy workaround?
EDIT: I forgot to mention that it probably doesn't have anything to do with the cookie path -- the cookies that don't work have a path of "/", and the cookies that do work have variously "/", "/application", and "/application/".
I figured it out! The problem was colons in the cookie names. Apparently the HTTP specification doesn't allow colons that aren't quoted. Tomcat started enforcing this in 5.5.26 -- coincidentally, I had been using 5.5.25.
It doesn't solve my problem -- these cookies are set by third-party software -- but it does answer the question!
If you have colons in your cookie names, either they need to be quoted (like so ":") or you need to use Tomcat 5.5.25 or older. I may try to configure my Apache proxy to modify the cookies on their way through... if that works, I'll update this answer.
There is some more detail about this in the comments on this bug report.
I might be late to a party, but I had a similar problem that required a much different solution.
The problem was in login data stored in cookies and then having the keys hard-coded in a file to confirm who is who. Due to WAR packaging, the paths got lost in a transfer, and the only thing I had to do was to correct the paths to right JSON files on a server.
Therefore, the issue was not in Tomcat but in a way the things got transferred and calls to those things.
Spent half of a day to locate the issue (I thought that there was some setting to be done in Tomcat), but then it was very simple once I realized that paths to a JSON were off.
I'm working on an assignment. An online order system using EJB 3.0. im using jDeveloper 10 and oracle 10g for the database. i have coded around 20%, now i need to check the system that i have developed so far. so when i run the web client it does not show me any error and it runs successfully. but when the browser tries to open the page it says. HTTP 500 internal error on the browser. My jsp page is under web directory anyway. output pic is attached.
how could solve this issue?
Are there any log files on your web server ?
Put in your code some statement to log to file what is doing.
Use a browser with developer support, like Firefox with Firebug, and watch the HTTP transactions.
Which other conditions change between web client and browser mode ?
how could solve this issue?
Look at the log files in your EJB server. There will probably be an entry or entries corresponding to your browser's attempting to fetch the page that resulted in the 500 error. They should give some information about what is happening, and may even give you a stack trace. Also check the SEVERE / ERROR / WARNING entries prior to the event.
If that doesn't give you an answer, you need to investigate what is different about the requests when they come from your web client versus from your browser. If your EJB implementation has a way to capture the incoming request headers, use that. Otherwise, you could use wireshark or tcpdump to capture them.
Thanks for your contributions.
I guess it was something wrong with my jdeveloper 10. i installed the jdeveloper 11 n i started running on it. the project started to run successfully.
We're trying to upload a file from a flex client to a Java EE app.
In a full HTTPS environment
Java EE server is JBoss 5
Using BlazeDS 'Custom' authentication (username and password are entered trhough a flex form)
Using BlazeDS per session authentication
In regular AMF calls, we can access user principal and use role mecanism.
However, in our upload servlet, we have no access to user principal.
request.getUserPrincipal() // returns null
How to fix this ?
A while ago a guy commented on a blog post of mine that https + flex + firefox doesn't work:
have you tried uploading a file in firefox via https? Well, don’t bother, it can’t be done! Adobe blames it on firefox and puts their head in the sand. Read the teeth gnashing and ridiculous claims of Adobe here:
http://bugs.adobe.com/jira/browse/FP-201
Ultimately they threw up their hands and said it couldn’t be fixed, and, although said ‘We understand that this is a serious issue and are committed to resolving it’ suggested that either you:
1) Send the file to your server in a different way
2) Find another form of authentication
This may no longer be the case - register and see if the linked bug is still unresolved.
Also - this might not be your exact issue (at least not yet) - I'm just giving pointers.
From your post, and since I haven't used BlazeDS, I can't tell whether you're running into this issue specifically, but it sounds to me like you are --
Take a look at your server logs, or try using a Web debugger like Fiddler (you can tweak it to reveal HTTPS traffic in clear text), and you'll see that Flash blocks custom HTTP auth headers with FileReference.upload(). Why it does, I've no idea, but there's no workaround I know of, other than crafting something or your own manually.