Hopefully a quick question.
I've just set up and launched a site and with Google's webmaster tools search console thing, I go to add my site which is great.
But I've been looking around to try and find what site URLs I should add. Here, google have a page regarding this:
https://support.google.com/webmasters/answer/34592?hl=en
On there it lists add the http and https sites separately.
I've set the config to redirect all requests to http, http + www and https to go to https://www.sitename if that makes sense.
The question is that in this case, should I add all 4 variants to google's webmaster tools or just the one that I'm using(https://www. version)?
You can add all versions, but that is not necessarily.
Also, you can set up preferred domain for google: https://support.google.com/webmasters/answer/44231
Actually, the best idea is to enter ALL your domain variants, including https variants if you use SSL for this reason: if you get penalties against a variant of your domain and you haven't registered it you will not see the warning messages in Google Search Console (Google Webmaster Tools) and never know what is killing your traffic.
Related
I am using this link for example to load the link. Although the link is a http link it will be redirected to a https link. It works in the browser.
However, as soon as I let my iOS Application load the resource it will say "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.".
I am using this library to load the picture. Is it not supported that Swift loads the https resource? I could think of that ATS blocks the connection to the server so the redirect can't even be received.
I would be very thankful for any thoughts on this.
Christian
While you certainly can disable the entirety of ATS using the solutions provided by Kishan and Johnson, if you know the domain of the http resource you are trying to load, you have better options. For details of why the disabling of ATS entirely is not the best idea, see this post.
Better options are:
If you know the http resource is always going to give you a redirect to the same https:// url, why not simply use the https:// url in your code. This won't work if the redirect is dynamic, but if your code is trying to load http://www.example.com/resource and that always redirects to https://www.example.com/resource, why not just change your code to go to the https version.
Only disable ATS for the domain in where you need to allow non https connections. This allows you to only allow http connections for domains you know don't support https, better protecting your application users.
Your ATS settings in your info.plist wqould look something like this:
If and only if your urls are driven by data that you don't control (i.e. the domains in those urls could be anything), you will need to disable all of ATS, and Apple may eventually want you to provide justification for disabling it. Originally they were going to have all ATS disabled apps go through an additional justification request processs, but they haven't mentioned that recently. This should be a last resort.
Honestly, looking at your example UR
Go to info.plist add a term called App Transport Security Settings.
And under that add Allow Arbitrary Loads
After the latest move by httpbin to HTTPS, apparently all sites that accepted test REST requests have disappeared. I've checked all mentioned in this post, and either they do not allow all kind of requests, or have also moved to HTTPS. For Raku modules such as this one, LWP::Simple, we need a HTTP-only site due to problems with certain operating systems. So is there any site left or will we have to roll out our own server?
You can use http://eu.httpbin.org. This URL doesn't redirect http to https.
http://www.neverssl.com/ and http://neverssl.com/ are another good options. They will never use HTTPS/SSL.
Note: Solved - question makes no sense, my understanding of CORS was incorrect and lead me to ask this question.
The answer is simple as pointed out by #CBroe below - CORS needs to be configured on the game server (in the example in this qestion).
I have a Facebook WebGL game that I'm wanting to host using Facebook's simple hosting (https://developers.facebook.com/docs/games/services/contenthosting/).
Is it possible to use Facebook's Simple Hosting for a WebGL game and still contact my web server (mygamedomain.com)? Is there somewhere in the FB app config to specify domains to allow?
Is the only way to get around this to serve the game from mygamedomain.com also?
I'd really like to avoid serving the game from my webserver if possible.
Any ideas or suggestions?
Not doing so will generate an error as expected:
XMLHttpRequest cannot load https://mygamedomin.com/mygame.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://apps-1287636812638.apps.fbsbx.com' is therefore not allowed access.
Just to be clear as there seems to be some confusion:
Game is hosted by facebook using their "Simple Hosting" service, not on my own server, .
I know CORS is the solution - the question is - does Facebook allow/support this? If so where do I configure the domains to allow.
If this was on my own server I the answer is trivial - CORS. But it's not.
There are hacks to circumvent cross-origin restrictions - I'm not looking for these. There's plenty of resources already covering these.
Edit: changed the title to more accurately reflect my question.
CORS is the solution to your problem here.
This question/the answer is not Facebook specific - the issue would be the same with any other domain serving your content, that is different from your own.
Your client-side code is hosted under the Facebook domain, and tries to make a request to your domain - that is the cross-domain part. Your domain is the party that holds the power to either allow or deny this request - by default, it would be denied, but by responding with the appropriate header, your server can signal to the browser, "yes, that's ok, he [your code running under facebook.com] is one of the good guys ..."
So you need to configure this on your server, that you want to make the request to.
I have a couple of web apps in azure (same codebase, in different regions) that I need to set up as end points in Traffic Manager.
One of those sites is already Live. It is configured to support multiple domains, but all requests are 301 redirected to a specific domain, for SEO reasons. The other site needs to work in the same way of course, within the Traffic Manager setup.
The issue is that Traffic Manager needs to be able to ping the *.azurewebsites.net domain and receive a 200 response to work, but with the current redirect rule in place on the endpoints, this will not work.
If I remove the redirect rule then Traffic Manager will work, but it means that requests for the sites at *.azurewebsites.net will not be redirected (and so presents an SEO concern).
The solution I'm heading towards is serving up a different robots.txt file (with a Disallow: / rule) if the request is for the azurewebsites.net domain. Is this feasible? How might I go about doing this?
Are there any other ways I could make this work?
thanks
I'm going to rework the current redirect rule so that it doesn't redirect for one particular path on the azurewebsites.net domain (*.azurewebsites.net/favicon.ico), which should enable Traffic Manager to ping the site, whilst keeping SEO ok for the rest of the Urls.
7 years later and some months, the answer seems to be in the traffic manager's config under other expected codes, so you can add 301-302 to that list to make your host health show online.
Using Google Apps for Work, there is a possibility to define custom URLs for Google Services (such as GMail, Google Calendar, ...), e.g. calendar.mydomain.com. These URLs redirect you to the respective Google Service and its usual domain URL, in this case https://www.google.com/calendar/b/2/render.
I was just curious whether there was a scenario, in which opening calendar.mydomain.com would not resolve in a redirect to http://www.google.com/calendar/hosted/mydomain.com". As a result you would still see the calendar.mydomain.com instead of the google calendar URL in your browser address bar. The common case seems to be, that invoking calendar.mydomain.com results in a 302 HTTP status code and you get redirected to the Google service.
This is the expected and supported behavior provided by Google as detailed here. I don't believe it'll be possible to prevent the redirection as you've detailed it.