I run a web server (RHEL7) that uses haproxy v1.5 as the front-end for remote client requests and host a farm of web-applications each running in specific directories off the web-doc root (i.e. /App001/, /App002/, etc..).
I recently renamed one of the application folders and reconfigured the app to use the new location and it works fine, but we have old documentation that points to the old app subfolder and I'd like haproxy to redirect the remote client requests seeking the old location (i.e. /OldAppFolder/) to the new location (/NewAppFolder/) to avoid a page-not-found error.
The redirect must be conditional such that it only redirects client requests seeking /OldAppFolder/*
Is this easy? Thank you!
This will rewrite the URL transparently to the user.
reqrep ^([^\ :]*)\ /OldAppFolder/(.*) \1\ /NewAppFolder/\2 if { path_beg /OldAppFolder/ }
Related
I recently added Fastly domain from addons in heroku application. And when fastly was provisioned I got a test url which is as follows:
https://felix-homes-herokuapp-com.global.ssl.fastly.net/
Whenever I click on this url it gets redirected to
https://felix-homes.herokuapp.com for some unknown reason.
Note my nodejs app uses Heroku-SSL-Redirect. Is it because of this?
I have already followed setup guide and asked multiple issues from the support
https://support.fastly.com/hc/en-us/requests/323620?page=1
And nearest question I find to SO is following
Adding Fastly to a Heroku app does not forward to proper url
Clearing browser cache or changing browser did not help me. Can you please try hitting fastly url on your computer and let me know if you are also face same redirect problem?
Yes, very likely the library (Heroku-SSL-Redirect) is the issue.
In the end, you have two separate requests. An encrypted HTTPS/SSL request from the browser. And then an unencrypted request from Fastly to Heroku.
Your node-application and the library only see the unencrypted request and return the redirect.
There are two ways to solve this:
You configure Fastly do do encrypted requests to Heroku as its backend.
Every routing / proxy layer (fastly, but also the Heroku routing layer) typically use the X-Forwarded-Proto HTTP header to tell the backend application that the initial request was already encrypted. So either heroku-ssl-redirect doesn't look at the header, or it did get lost somewhere on way.
I'm developing a site that's virtually entirely static. I use a generator to create all the HTML.
However, my site is a front-end to a store embedded in its pages. I have a little node.js server proxying requests on behalf of the browser to the back-end store. All it does is provide the number of items in the shopping cart so I can keep the number updated on all pages of my site. That's because the browser doesn't allow cross-domain scripting. My server has to act as a proxy between the client and the store.
(The embedded store is loaded from the store's web site and so itself does not require proxying.)
I was hoping to eventually deploy to Netlify or some similar JAMstack provider. But I don't see how I'd proxy on Netlify.
What is the standard solution to this problem? Or is proxying unavailable to JAMstack solutions? Are there JAMstack providers that solve this problem?
Netlify does allow for proxy rewrites using redirect paths with status code 200.
You can store your proxy redirects in _redirects at the root of your deployed site. In other words the file needs to exist at the root of the site directory to be deployed after a build.
_redirects
/api/* https://api.example.com/:splat 200
So a call to:
/api/v1/gifs/random?tag=cat&api_key=your_api_key
will be proxied to:
https://api.example.com/v1/gifs/random?tag=cat&api_key=your_api_key
If the API supports standard HTTP caching mechanisms like Etags or Last-Modified headers, the responses will even get cached by CDN nodes.
NOTE: you can also setup your redirects in your netlify.toml
Anytime a user tries to access our site with http, they are redirected to https via this code in the Application.cfc:
If (CGI.HTTPS != "on") {
location(url="https://#Application.PortalApp.GetDomain()##CGI.SCRIPT_NAME#?#CGI.QUERY_STRING#", addtoken="false");
}
The strange thing is, if they have never accessed the site via http, but happen to click an internal link that points to http instead of https, they are logged out. However, once they login again, they can then access an http link, get redirected to https and stay logged into the system.
I did some line-by-line debugging and the https session gets overwritten when a user access http. But once a user accesses http, the https shares the sessionid.
Is this correct behavior?
In ColdFusion Administrator Session settings, HTTPOnly is set to true, and secure cookie is set to false.
Think of them as two completely separate domains.
The session under HTTPS is a completely different session from the one under HTTP. That's just how that works.
Instead of controlling it at the application code level, you should configure your web server to only allow connections over HTTPS and automatically redirect HTTP requests to HTTPS.
Here's a link for IIS.
Here's a link for Apache.
More info can be found in this Google Developer page, but I'll paste the highlights.
HTTPS protects the integrity of your website
HTTPS helps prevent intruders from tampering with the communications between your websites and your users’ browsers. Intruders include intentionally malicious attackers, and legitimate but intrusive companies, such as ISPs or hotels that inject ads into pages.
HTTPS protects the privacy and security of your users
HTTPS prevents intruders from being able to passively listen in on the communications between your websites and your users.
You'll want to make sure that internal links on your site are never explicitly using HTTPS, so look into setting <base href="https://{yourDomain}" > in your layout files to force all relative URLs to use HTTPS.
I've been having the same problem and this fixed it.
On Server2008, in IIS Manager, open up the ASP properties, expand "session properties", and change "New ID On Secure Connection" to "false".
A couple suggestions:
Easy one first: this may not be the right direction, but what happens if, instead of using CGI.HTTPS, you use CGI.SERVER_PORT_SECURE?
If CF is overwriting the session when you switch from https to http, why not just handle this on the front end with the web server rather than through CF? IIS and Apache all have easy rewrites or redirects that may save you some time over trying to deal with CF, particularly if your whole application is secure anyway.
It seems that the check for user being logged in is before the http to https check and redirect. If possible you should check for https first (redirect if is http) then check for logged in.
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
I use a third-party application that requests a config file from their Internet site. That file is out of date, but I can create my own file with the updated information.
How can I redirect any requests coming from my computer for a specific URL to a different file? For example, if any application requests http://www.theirsite.com/path/to/file.html, cause it instead to receive http://www.example.com/blah.html or C:\My Documents\blah.html?
Why not change your hosts file to point lookups to their website to a web server that you control ? Then add your own config file. You may have to redirect other requests to their server though, if the app uses the website for other resources.