I have github pages website which makes request to a hosted server which is HTTP and my browser blocks it.
Its assignment for university so I don't really want to pay for HTTPS on the server and I can't use something else for the front-end as I have sent the url to my professor expecting that this is where my web app will be hosted.
Is there anything I can do, which doesn't involve paying that much money?
I encountered this same issue when making API calls. Here's an easy workaround:
Get your api endpoint (for this example, let’s say
http://api.catphotos.io/)
Prepend the CORS API link https://cors-anywhere.herokuapp.com/ to
your link
Make sure to leave the http:// on your endpoint.
Your new link should look like this:
https://cors-anywhere.herokuapp.com/http://api.catphotos.io/
Make your API calls with your new link!
Source: johnalcher.me
According to the GitHub Pages help docs:
HTTPS enforcement is required for GitHub Pages sites created after June 15, 2016 and using a github.io domain.
That means you can't disable the https:// redirect. You could use a custom domain which then leaves the https:// stuff up to you.
Or you could move the stuff from the other server to GitHub Pages, assuming it's not too big.
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
I had the SSL installed on my site for a day and uninstalled it. Now in serps, google shows some of the pages in https version. I don't think this is a duplicate content issue because only one version of the web page shows up in serps. I'm not sure how to fix this because the mix of http hand https show up.
Why does google randomly show https version of my pages?
How can i tell google to use the http version of those random pages?
Thanks in advance!
I think more information is needed to fully answer this question, however, most likely Google is showing the HTTPS version of your page because your site was using HTTPs at the time when Google visited and indexed your page, thus the HTTPS version was cached.
You can partially manage your search page and request that Google re-index your site from Google Web Developer tools. https://www.google.com/webmasters/tools/. However, the change isn't guaranteed and won't take place immediately.
Furthermore, you can control whether a visitor uses HTTPS or HTTP when visiting your site via standard redirects. In other words, update your webserver or web application so if someone visits http://mysite they will be redirected (preferably with a 301 status code for SEO reasons) to https://mysite.
Finally, as a general practice, you should really use HTTPS as browsers may highlight warnings for non-secured traffic in the future. For sites I manage, "http" requests are automatically redirected to the "https" of the same URL to ensure all traffic is always over a secure connection.
First I'm not in the web side of our world, so be nice with the backend guy.
A quick background : For a personal need I've developped a google chrome extension. They are basically a webpage loaded in a chrome windows and... yeah that's it. Everything is on the client side (scripts, styles, images, etc...) Only the data are coming from a server through ajax calls. A cron job call a php script every hours to generate two files. One, data.json contains the "latest" datas in a json format. Another one hash.json contain the hash of the data. The client chrome application use local storage. If the remote hash differ from the local one, he simply retrieve the data file from the remote server.
As I have a BizSpark account with Azure my first idea was : Azure Web Site with php for the script, a simple homepage and the generated file and the Azure Scheduler for the jobs.
I've developed everything locally and everything is running fine... but once on the azure plateform I get this error
XMLHttpRequest cannot load http://tso-mc-ws.azurewebsites.net/Core/hash.json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:23415' is therefore not allowed access.
But what I really can't understand is that I'm able (and you'll be too) to get the file with my browser... So I just don't get it... I've also tried based on some post I've found on SO and other site to manipulate the config, add extra headers, nothing seems to be working...
Any idea ?
But what I really can't understand is that I'm able (and you'll be
too) to get the file with my browser... So I just don't get it
So when you type in http://tso-mc-ws.azurewebsites.net/Core/hash.json in your browser's address bar, it is not a cross-domain request. However when you make an AJAX request from an application which is running in a different domain (http://localhost:23415 in your case), that's a cross-domain request and because CORS is not enabled on your website, you get the error.
As far as enabling CORS is concerned, please take a look at this thread: HTTP OPTIONS request on Azure Websites fails due to CORS. I've never worked with PHP/Azure Websites so I may be wrong with this link but hopefully it should point you in the right direction.
Ok, will perhap's be little troll answer but not my point (I'm .net consultant so... nothing against MS).
I pick a linux azure virtual machine, installed apache and php, configure apache, set some rights and define the header for the CROS and configure a cron in +/- 30minutes... As my goal is to get it running the problem is solved, it's running.
Building an app using a calendar on a Google Apps domain that has SSL enforced domain-wide. I initially found the problem when building a Rails app using the GCal4Ruby library, which used the allcalendars feed URL with a non-SSL protocol (GCal4Ruby debug output snippet [sic]):
…
url = http://www.google.com/calendar/feeds/default/allcalendars/full
Starting post
Header: AuthorizationGoogleLogin auth=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGData-Version2.1
Redirect recieved, resending get to https://www.google.com/calendar/feeds/default/allcalendars/full?gsessionid=xxxxxxxxxxxxxxxxxxxxxx
Redirect recieved, resending get to https://www.google.com/calendar/feeds/default/allcalendars/full?gsessionid=xxxxxxxxxxxxxxxxxxxxxx
Redirect recieved, resending get to https://www.google.com/calendar/feeds/default/allcalendars/full?gsessionid=xxxxxxxxxxxxxxxxxxxxxx
…
This was interesting because it seemed to continue forever. I think I've fixed this in GCal4Ruby locally by creating the ability to use the allcalendars feed with the HTTPS protocol (i.e: https://www.google.com/calendar/feeds/default/allcalendars/full).
The thing that worries me is that I see no mention of the allcalendars feed needing to specify the HTTPS protocol in the Google documentation. That, and the fact that when I access the same domain using the Zend GData library in PHP, it works fine accessing the non-SSL private feed (i.e. http://www.google.com/calendar/feeds/r-calendar.com_xxxxxxxxxxxxxxxxxxxxxxxxxxx%40group.calendar.google.com/private/full).
So, the question: What am I misunderstanding? Is it just the allcalendars feed that needs to be accessed with SSL and the rest of the private feeds can safely use the authentication token?
Anyone have any insight, or pointers to some good docs?
So, it looks like perhaps redirect to the normal URL is normal for authentication, but that the library is not handling the redirect correctly because of some differences between the way Google Apps and Accounts work on the backend. This is in contrast to the Zend library, which seems to handle this more robustly. That's my current guess, anyway.