having an issue with my app now I have setup SSL on it.
I do use URL::previous and Route::back() in a few places, however since applying an SSL cert to my site, these methods do not seem to play nice or get the correct url / route they used to.
Is this to do with the SSL having to make multiple requests?
Thanks!
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 am trying to create a route under Symfony4 in https mode. My online research has taught me that I have to present the route in the annotation as follows: #Route ("/lucky", name = "lucky", schemes = {"https"}). But the request made from Chrome gives me the message "This site is inaccessible." Are there any other settings to perform?
I think I found the answer. To accept HTTPS requests, a server must have a certificate. Since this is a local wamp server, wamp must be set to install an SSL certificate. The attached documentation explains how to do:
enter link description here
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.
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.
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