I have a problem in request and responses in a Spring MVC application.
When I hit https://test.abc.com/AppName/security.do in a browser. response url is coming like https://test.abc.com:455/AppName/security.do
In Response Headers Content-Location: https://test.abc.com:455/AppName/security.do
Because of the port appended, application is not accessable. At what stage I can remove or redirect test.abc.com:445 to test.abc.com.
Application is hosted Oracle Server and uses Apache Webserver before that request will travel through content switch.
Thanks
Sunny
The solution is, I think, to set UseCanoncalName variable in Apache config to Off.
Related
I have a spring boot application which works over http.I do not want to touch the application - so no keystore etc. I want to use reverse proxy - i.e. the request will land at some other machine over TLS and
will get redirected to my spring boot application over secure socket layer. How it could be done?
Edit: When I try to login to that site, developer tool console tells me:
"Mixed Content: The page at 'https://xxxx-uat.xxxx.com:4200/login' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://151.253.73.106:9091/login'. This request has been blocked; the content must be served over HTTPS."
Nginx reverse proxy is being used.
Best way to do it is to use cloudflare. Cloudflare is free for basic use. You can create a new site, point to your HTTP URL and configure SSL as flexible. So, now your service is behind https. Cloudflare will act as proxy. Request will go to cloudflare via https, then it will be routed to your http.
I'm trying to redirect all traffic hitting HTTP to HTTPS on my application. Nginx is handling generating keys and certificate signing requests.
HTTPS works perfectly when we type it in manually in the browser's address bar. So to force all HTTP requests to use HTTPS we are changing Spring configuration in various ways.
When adding the requires-channel="https" attribute to <intercept-url/> in our .xml we are getting a 302 redirect loop. We tried declaring the port mappings in a Spring config .xml as suggested in this SO answer but it made no difference to the redirect loop. HTTPS is looping on itself by looking at the network tab in chrome dev tools.
Any help/ideas are appreciated, thanks.
I am using NGINX as my web server for html/js/css files and my web app UI. It is a single page app that uses AJAX requests to a back end JEtty server. Previously I deployed everything in Jetty and ajax calls worked fine. In separating the back end from the web UI tier, I am now trying to figure out how to configure NGINX to allow AJAX requests to pass through to Jetty. But, I ALSO want to prevent someone from watching network traffic and seeing the ajax calls my app makes, then scripting those themselves. To do this, I believe if I can configure nginx to ADD a custom header to the requests as they pass through (is this even possible?) I could then only accept requests with those headers at my Jetty API level.
If that is possible, is it the right way to handle this so that outsiders can't get in to my back end API? Is there a way they could figure out that my nginx server is adding a header short of breaking in to my server and figuring out the configuration?
If your application calls your api via Ajax on the client there's nothing you can do to stop someone from calling it directly (assuming they otherwise have access to the page). At the end of the day, an Ajax request is just a request made from the client in JS. Now, there are lots of stupid ways to make it more difficult, but, if anyone really wants to call your api directly, they can.
If you're just talking about only allowing access through nginx (or specifically your /api location block), just bind jetty to localhost only.
I have a problem with struts2 and redirect-action over https.
Basically the redirect response I get back from my https request has a non-secure location (i.e. http://...).
So that means the browser goes from a secure session to a non-secure session.
Any idea what could cause this?
Cheers,
Stuart.
The problem was not in Struts 2 although the solution posted by Umesh would also have worked.
The environment I was working in had the SSL connections terminated by a load balancer before it reached the Apache front end. This meant the AJP request to Tomcat appeared to be HTTP and the redirect URL in the response from the Struts redirect-action was written as HTTP.
The solution I chose was to write a separate connector in tomcat's server.xml for the HTTPS connections, specifying:
secure="true"
scheme="https"
proxyPort="443"
Struts 2 itself does not support SSL switching by default
If you are switching from HTTPS mode to HTTP and vice-versa my best bet is to use Struts2-ssl plugin.
This plugin will take care of the switching based on the method annotation or the configuration you have provides.
here are the details
Struts2-SSL plugin
I have been trying to get this resolved, without any success.
I have a webapp residing on my domain, say www.myDomain.com. I need to call a service which is present on another domain, say www.anotherDomain.com/service.do?
I'm using SproutCore's SC.Request.getUrl(www.anotherDomain.com/service.do?) to call that service.
I get an error that says, Origin www.myDomain.com is not allowed by access-control-allow-origin.
When I was in dev stages, and using sc-server, the issue was resolved using proxies. Now that I have deployed the app to an actual server, I replaced all the lines where I had set up the proxy with the actual domain name. I have started getting that error again.
The problem is that I CANNOT MAKE ANY CHANGES to the server on the other domain. All the posts that I have come across state that the other server on the other domain ought to provide access-control-allow-origin header and that it ought to support the OPTIONS verb.
My question is, is it possible for me to connect to that service using SproutCore's SC.Request.getUrl() method?
Additionally, the other posts that I have read mentioned that a simple GET request ought not to be preflighted. Why then are my requests going as OPTION instead of GET?
Thanks a ton in advance! :D
This is not a Sproutcore issue; it's a javascript Same Origin Policy issue.
If you can't modify the production server, you have no option but to develop your own proxy server, and have your proxy hit the real service.
This is effectively replacing sc-server in your production environment.
All this server would do is take the incoming request and pass it along to www.anotherDomain.com/?service.do.
You would need to make sure you passed all parameters, cookies, headers, the http verb, etc....
This is far from ideal, because now errors can occur in more places. Did the real service fail? Did the proxy fail? etc.
If you could modify the other domain, you could
1) deploy your SC app there.
2) put in the CORS headers so you could make cross domain requests