I want disable http requests, and only use https requests in jetty-9.4.26, what I did is in start.ini, I disabled this: #--module=http, but it is not worked. is there any config that I missed?
I disabled start.ini and stard.d/http.ini's config: #--module=http, but I can still using http://xxx to access my application.
Related
I have configuration
Symfony in nginx https + varnish + apache http = redirect loop
i put schemes for routing to get links https : ['https']
but get redirect loop why ?
it look that symfony not just create links with https but return redirect if get http - i need http pages for cache in varnish but links https.
Update 1
When i put no schema in routing and run page over https almost everything work - without
1 fos routing it create absolute http links
2 liip imagine same situation
If you are getting a redirect to https despite using https when visiting the page, then the original protocol is not being forwarded to the backend that handles the response.
There is a header X-Forwarded-Proto which should be set to contain the original protocol before it was passed through any proxies. Symfony should respect this header and accept that the request is secure and not redirect (and also set all links to https:// urls if appropriate)
You need to configure Apache (which I assume is terminating the https connection and has the certificates) to set this header to match the original request protocol.
It looks like you might need to trust the proxies before Symfony will obey the headers Symfony Docs for proxies
// public/index.php
// ...
$request = Request::createFromGlobals();
// tell Symfony about your reverse proxy
Request::setTrustedProxies(
// the IP address (or range) of your proxy
['192.0.0.1', '10.0.0.0/8'],
// trust *all* "X-Forwarded-*" headers
Request::HEADER_X_FORWARDED_ALL
);
Let me start by saying that I have thoroughly looked over all information on stackoverflow and the net in regards to this issue, and I have tried several different things to try and get this working.
I am using the package "cookie-session", but when I set secure to true, my cookies are sent with the request (I can see making a login request with Postman) but the session seems like it is not working through the browser. When secure is set to false everything is fine, works as expected.
Let me explain my setup, I have two servers:
First Server
Serverside rendered React App running Node JS
Running Nginx server
HTTPS is setup here "www.example.com"
Proxying any requests made to "www.example.com/api" to second server
Second Server
Node/express app handling API requests
Running Nginx server
From my understanding, a secure cookie can only be sent if the request is made through HTTPS. Which I believe it is (setup above).
On the second server I have tried using the trust proxy, still no luck:
app.set('trust proxy', 1);
app.use(cookieSession({
maxAge: 7 * 24 * 60 * 60 * 1000,
keys: [env.SESSION.COOKIE_KEY],
secure: true
}));
I also figured that this may have something to do with the headers that are sent with Nginx, I have tried many different headers on both servers e.g. (proxy_set_header X-Forwarded-Proto $scheme), still no luck.
For the life of me I am not sure what to do from here to get secure cookies working.
Also to mention again that everything works fine with secure set to false. When secure is set to true, I can make a request through Postman to my login and receive my cookies in the request, but it appears the session is not applied on the client.
Could this have anything to do with not having a HTTPS cert installed on the second server? If so, how would I add one anyways as both servers run on the same domain "www.example.com" + proxy /api requests to "www.example.com/api"? Thanks for your help.
I have an application which is accessed via HTTPS, but is "reverse proxied" to the server using plain HTTP. It is set up on AWS as follows:
[BROWSER] --(https)--> [ELB] --(http)--> [SERVER]
Everything works fine except when a page is being accessed by an unauthenticated user, the server responds with a HTTP 302 redirect using the whole protocol://server/path string. Like so:
Location: http://my.server.com/Account/Login?ReturnUrl=%2F
The problem is, it specifies HTTP as the protocol (presumably because it is being connected to by the ELB using HTTP. So the browser redirects the request using HTTP and now an error occurs. Is there a way to customize the redirect such that it redirects using just the path, so irregardless of protocol or hostname, it is redirected properly? Like so:
Location: /Account/Login?ReturnUrl=%2F
If this is not advisable, what can be done?
(note: I've checked other solutions posted on SO. All I've seen so far involve customizing the Path, not removing the protocol://hostname)
I am restricted some folders in my server to http and https using htacess, In some of my non https pages, I need to call a ajax script (php) which is using https (In the same domain), it is not working (https to https are working fine ).
I have tutorials/ path which is rewritten to use http only, i have one more folder(path) ajax/ rewritten to use https and I am making a call from tutorials/ to ajax/, it is failing.
It is the restriction of ajax for security reasons that you can not access any https page from http page. It is recommended that If you want to use https then all of the pages in your website must be accessed using https. To ensure this you should use relative path. If you use related path then http or https will automatically be calculated based on the source page from where you are accessing other page.
I'm developing your standard high traffic ecommerce website and want to setup caching with Varnish. The particular thing on this setup is that the application will return different content depending on the user's particular location.
So my plans are these:
Setup Nginx with GeoIP module, so I can get a X-Country: XX header on all the requests going to the app backends.
Configure the Rails application to always return a "Vary: X-Country" response header.
Put the Varnish server behind the Nginx and the app backends, so it can cache multiple versions of the objects served by Rails, and serve them based on the request headers set by Nginx (not the client browser)
Does anyone have experience with a setup like this? Anything I should be aware of?
If GeoIP lookup is slow, and/or you want to enable people to override the country setting, you could use a country cookie and have the front-end Varnish check for it.
If there is no country cookie, forward the request to your nginx back-end for GeoIP lookup. Nginx serves a redirect with a Set-Cookie: country=us header. If you want to avoid redirects and support cookie-refusing clients/robots, ngingx can forward it to Rails and still try to set the country cookie in the response. Or Varnish can capture the redirect response and do a "restart" with the newly set cookie and go to the back-end
If you have already have a country cookie, use this in your Varnish hash
If Rails can do GeoIP resolving, you don't need Ngingx, except when you use it to serve files...