I'm trying to redirect all https traffic to http using this in Sinatra
get "*" do
if request.secure?
redirect request.url.gsub(/^https/, "http")
else
pass # continue execution
end
end
However, on a custom domain on heroku, my browser shows me the error:
This is probably not the site you are looking for!
You attempted to reach www.[domain].com, but instead you actually reached a server identifying itself as *.heroku.com.
My DNS is configured with the www subdomain having a CNAME pointing to [domain].herokuapp.com as per https://devcenter.heroku.com/articles/custom-domains
Is this a DNS issue? Is buying a SSL certificate the only way to allow all https traffic to redirect to http, on heroku?
If you were going to use that code then I'd make it a before filter, as that's really what it is.
However, if you've received a request at the application layer (which is where your Sinatra app sits on Heroku) then you need a certificate because the HTTP layer (where the Nginx proxy servers that deal with this sit) has already received the request and will attempt to deal with it as a secure connection but fail/raise an error because there's no certificate. That is the message you'll get if you try and reach an non SSL page/site via the https URI scheme. You can still access the site but the user has to click past a scary warning.
The only way I know of that may work without a certificate (but looking at this answer probably not) is if you had access to the Nginx configuration and did the rewrite of the URL (and probably some headers) there.
Related
I'm able to verify the webhook using glitch from the getting started:
https://glitch.com/edit/?fbclid=IwAR2YTjZuGGM9Hi6T_v1eZh_nV6_HY3RYn_8lll4gY1REa_bJy6ZAuq6tkKQ#!/whatsapp-cloud-api-echo-bot
my local server (in a subdomain with https enabled) has the same behavior as glitch and show "WEBHOOK_VERIFIED" on the log for the request:
/webhook?hub.mode=subscribe&hub.verify_token=xpto123&hub.challenge=123
but when try to verify my local server the request from meta does not reach the server.
chrome showing that the connection to the server is secured
After more tests I found that my local server was been blocked by the ISP, understood it after test with another connection.
I made my own server and had tried ngrok and other programs to run it from local host with https redirect but whatsapp doesn't allow the use of those programs.
In the end, my error was that the URL HAS to end in /webhook or else, it won't even send the request. Then it'll send a GET request and you have to return the hub.challenge query param after making sure that the provided token from them is the one you set up. This is my code using NodeJS
if(req.query['hub.verify_token'] === process.env.VERIFY_TOKEN) return res.status(200).send(req.query['hub.challenge'])
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.
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 a local site running ASP.Net MVC 3 over HTTP and HTTPS through IIS Express.
The HTTP url is http://localhost:4000 and the HTTPS is https://localhost:44301.
I'm trying to hook up the Stripe payments API but it really does not like the port, protocol and domain mismatch. I've tried using CORS to tell it to trust stripe.com but it seems that it is due to the port mismatch and I cannot figure out how to tell it to ignore that.
Adding the following header does not product any difference.
Access-Control-Allow-Origin:*
When accessing my payment page via HTTP, I get the following:
Blocked a frame with origin "https://checkout.stripe.com" from
accessing a frame with origin "http://localhost:4000". The frame
requesting access has a protocol of "https", the frame being accessed
has a protocol of "http". Protocols must match.
It gets worse when using SSL as my local SSL port is not 443.
How do I tell CORS to ignore the port mismatch whilst in development?
You can disable same origin policy while in development. Load chrome with the following argument:
--disable-web-security
https://stackoverflow.com/a/6083677/287760
Didn't the error message tell you the problem? Use HTTPs.
I still get this message my live site:
Uncaught SecurityError: Blocked a frame with origin "https://checkout.stripe.com" from accessing a frame with origin "https://getaddress.io". Protocols, domains, and ports must match.
..everything still works so I wouldn't worry about it. There's not much you can do about the domains being different.
I'm developing on Heroku a site with a couple of subdomains. One of them is signup (as in signup.myapp.com) which requires SSL access -- of course! But the rest of the subdomains, such as www, do not require https to access.
The problem is that the client only purchased an SSL certification for signup.myapp.com. This means that, when a user tries to access other places of my site with https (such as https://www.myapp.com), SSL certification does not validate and browsers tell the user that the site could be malicious... not good for branding.
I tried to make the site redirect from https to http, but of course this failed, because SSL was checked before the redirect could be sent.
Is there a way that I can deny access to these places of my site from https, so that users encounter, for instance, a 404 page instead? Or, do you know of any other ways to handle this situation? (the client is reticent to acquire a new SSL certificate, specially a wildcard certificate).
Unfortunately, you need a certificate for each of the domains (or a wildcard one as you mention), see e.g.:
How to redirect https to http without any SSL Certificate
The problem is that certificate is the first thing checked, way before anything else happens. If that fails, browser will typically display "get me out of here!"-kind of notification. There's no built in support for SSL-to-non-SSL transition.
You can shut down https://www.example.com (i.e. make your Web server not listen on port 443), but that of course won't yield a 404, also bad for branding.
With just one non-wildcard certificate, the only thing you can do is put all the pages under that domain. I.e. instead of https://signup.example.com/a/b/c, you need to do https://www.example.com/signup/a/b/c or something along those lines.
On the other hand, you can buy the certificate for under $100/year (or $150 total for 2 years) at GoDaddy:
http://www.godaddy.com/ssl/ssl-certificates.aspx
so, depending on your context, it might just pay off to pay this instead of doing any additional development.