I'm having an unending issue trying to use the AppEngine API explorer with the stupidly simple helloworld example.
When trying to navigate to the url to explore the API my Chrome browser redirects to HTTPS from the default HTTP and no API's are listed. I have gone through every possible fix I can find (Like this, and all of these) and none are working reliably.
What's the most infuriating is I have gotten the API listed TWICE but now no longer displays with any of the methods below.
The setup I had when it worked the first time:
Chrome launched with "C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe" --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 (As per the tutorial)
The url being: (http://)apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api&root=http://localhost:8080/_ah/api#p/
The second time it worked was using also using the above URL but lasted only a second before being redirected to HTTPS and not listing anything.
Some specifics:
Windows 10 OS.
Every time the page loads I get the "The API you are exploring is hosted over HTTP, which can cause problems. Learn how to use Explorer with a local HTTP API." message, even the times the API displayed correctly.
Every time I now load any of the API Explorer URLs I get redirected to HTTPS, and nothing is listed. Also the URL is escaped (%3A instead of ':'). Not sure if it's important but the first time it worked the URL was HTTP and NOT escaped.
I have tried the shield in the search bar and enabling Load unsafe scripts ( from here).
Tried launching Chrome as usual and with the flags --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 and/or --allow-running-insecure-content (from this answer).
Tried http://localhost:8080/_ah/api/explorer
Tried http://apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api#p/
http://localhost:8080/_ah/admin works correctly and shows the Admin console every time.
Since the API's being listed once I haven't touched the project code, but restarted the server, Chrome, and tried different URLs on more occasions than I care to count.
I also tried accessing the API URL directly as explained in this answer but cannot find the correct URL to access the helloworld /sayHi endpoint. Maybe someone can help me work out what I need to prefix it with as all of the variations I try give me a 404.
Any help would be a very very appreciated.
Related
A friend of mine has been having trouble getting her site indexed by google and asked me to have a look, but that is not something I really know much about and was hoping for some assistance.
Looking at her search console, google crawl shows an error of soft-404 on the index page. I marked this as fixed a few times, because the site looks fine to me but it keeps coming back.
If I fetch the site as google it seems to be working fine, although it is showing the mobile version instead of the desktop.
It keeps giving another reoccurring 404 of a page http://www.smeyan.com/new-page, which doesn't exist anywhere I can see including server files or sitemaps.
Here is what I know about this site:
It used to be a wix site and was moved to a host gator shared server 2-3 months ago.
It's using JavaScript/jQuery .load to get page content outside the index.html template.
It has 2 sitemaps one for the URLs and one for both URLs and images
http://www.smeyan.com/sitemap_url.xml http://www.smeyan.com/sitemap.xml
It has been about 2 months since it was submitted for indexing and google has not indexed any of the content when you search for site:www.smeyan.com it shows some old stuff from the wix server. Although search console says it has 172 images indexed.
it has www. as a preference set in search console.
Has anyone experienced this and has an direction for a fix?
How long time was set for this site in Cache-Control header? If long, you should use "google removals" for obsolete snippets and cache. I simulated Google visit on your webpage. Correct 404 return code. Correct headers. Thus. Report google removals for "not found" pages. You must request visit of Googlebot and keep calm and wait for reaction.
BTW: For permanently removed content use 410 Gone for Google or... report via Removals.
https://support.google.com/webmasters/answer/1663419?hl=en
The only download error that I saw while using Chrome's Inspect function pertains to a SCRIPT tag with a Facebook url as the source (src) file.
This is the error as reported by Inspect.
This is the SCRIPT tag that caused the error.
I am not sure that this is the cause of the reoccurring 404 error, but it is an issue that needs attention on this website.
I checked your site with Tor Browser which has... DISABLED SCRIPTS. You should provide any content on your site with use of <noscript/> tag. It doesn't have to be beautiful but should be visible for bots. <a href... ></a>, <img/> etc. and... TEXT. Without it the site is NOT OPTIMIZED for search bots. Read about SEO. The sitemap content can be never indexed if the content will be never linked.
Probably your webpage also doesn't meet requirements for screen readers (for blind people).
Note: The image with "SMEYAN" caption is visible on webpage and is indexed.
second image on the webpage (in source): <img class="gallery-full-image" src="./galleries/home_gallery/smeyan_home-1.jpg" /> and indexed
The menu also doesn't work without scripts.
I thought the step is good implemented.
Please use <noscript/> element and implement version for blind people (without scripts, provide alt tag for images) and for noscript browsers. You can test it via disabling script or via NOSCRIPT extension for Firefox.
BTW. You should use HTML, CSS (including animations) and... use the JS ONLY if it is needed. Or... <noscript/> method.
Google bot currently use web rendering service (WRS) that is based on old Chrome 41 (M41), so it may fail where browsers succeed.
To learn how google boot works read this.
Add this code to the page to see the real error.
You can see the error using Url Inspector live, from google search console. It will show at more info tab.
Note: if the bot gets a 301 code or if the page is too little to have significant content it will return a soft 404 error, and won't preview or show any other error.
I'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.
We have a CMS that powers over 2000 school websites. The admin sites for each of those websites are all under the same root domain, e.g. *.myadmin.com. We are working on integrating OneDrive File Picker on multiple pages in all of those admin sites.
We have an issue with the Redirect URLs in the API Settings. We tried to set the Root domain field to myadmin.com by setting Redirect URLs: to https://myadmin.com. In JavaScript, we initialize the File Picker like this:
WL.init({
client_id: window.OneDrive.clientId,
redirect_uri: ''
});
WL.fileDialog({
mode: "open",
select: "single"
});
That results in a popup window saying:
We're unable to complete your request. Microsoft account is experiencing technical problems. Please try again later.
In the address bar of the popup window, there's a further error description(url decoded):
error_description=The provided value for the input parameter 'redirect_uri' is not valid. The expected value is 'https://login.live.com/oauth20_desktop.srf' or a URL which matches the redirect URI registered for this client application.
Putting a specific url, like https://subdomain.myadmin.com/homepage, in the API Setting would make the Picker work on that specific page, but not on other pages. Looks like it's looking for an exact match. Obviously it's not practical for us to create a separate app for each page that uses OneDrive.
The problem can be solved by disabling Enhanced redirection security on the API Settings page. That option existed a few weeks ago when we created an app for development, but was marked as deprecated. Today when we created a new app for production, it wasn't there anymore, which I think is now enabled for all new apps.
We had a similar issue with Dropbox Drop-ins Chooser, but we were able to solve the problem by setting myadmin.com as the domain of the app.
Is there any work around for this problem?
Thanks for your help and suggestions.
The only way I could get this to work was
Make sure the exact single web page on a single domain is configured and working for one drive (the url running OneDrive needs to be correctly configured in Microsoft account Developer Center
Then use this page inside an iframe (even if it is a completely different domain)
then use postMessage to pass the data back to the parent iframe to utilise
a working copy (link may be removed at any time )
Testing OneDrive in an iframe
Other pertinent urls
browser support for postMessage
Browser support for postMessage on stackoverflow
postMessage documentation
Some example usage of postMessage
example usage of postMessage
another example of use of postMessage
You can add multiple Redirect URLs as long as all of them are in the same subdomain. Each redirection URL needs to be specified explicitly:
The bug with the Microsoft developer console mention is resolved if you put the root domain you want first, then the 2 sub domains.
Add 3 entires:
1. domain.com
2. sub1.domain.com
3. sub2.domain.com
I'm writing an app for Facebook, which needs to be secure. The initial page, https://myapp.com, loads perfectly fine.
However when I click a link to https://myapp.com/link, Chrome complains that the app is trying to load from an insecure source. I get the following message in the console:
"[blocked] The page at 'https://www.facebook.com/page/app_###' was loaded over HTTPS, but ran insecure content from 'http://myapp.com/link/': this content should also be loaded over HTTPS."
Now the link is an absolute URL with the https prefix, yet apparently the page is trying to load from the http version.
I visited the domain itself and checked the Network tab in the Chrome console to see what was happening. The following happens:
The GET to https://myapp.com/link is a 301, moved permanently.
This then redirects to http://myapp.com/link
As far as I can tell, there is nothing in my python code to make this happen, so I suspect some feature of Heroku is causing this, but I haven't been able to find anyone else with this problem.
As a side note, I used Flask-SSLify to add a redirect back to the https version. This redirect works, but Chrome still blocks the page because it passes through the insecure version.
I feel so stupid for working this out five minutes after posting the question, but it is a little obscure.
It turns out the problem was that the page I was attempting to reach was "https://myapp.com/link/" with the trailing slash.
"https://myapp.com/link" redirects to "http://myapp.com/link/".
I don't know why the protocol isn't preserved by this redirect, it may be either Flask or Heroku, though I suspect it is Flask. Regardless it seems like a bug.
Hope this winds up helping somebody else.
I've been looking for this answer and the other pages didn't help me.
I'm trying to use the google drive api for php. I am trying to test on my local environment and receive this error.
Error: redirect_uri_mismatch
The redirect URI in the request: urn:ietf:wg:oauth:2.0:oob did not match a registered redirect URI
Request Details
scope=https://www.googleapis.com/auth/drive
response_type=code
redirect_uri=urn:ietf:wg:oauth:2.0:oob
access_type=offline
display=page
prompt=consent
client_id=735129338633-0epug8n80jsg0t50ijn7our4a661nnk6.apps.googleusercontent.com
Here is the page for the api:
The url is in
localhost:8888/Spreadsheets/driver.php
What am I doing wrong?
Looks like the current Google OAuth2 integration requires enabling
Contacts API
Google+ API
from the Google Developers Console for the associated Project. In my log I noticed errors liek 403, Access Not Configured. Please use ....
The redirect URI (where the response is returned to) has to be correct and exactly as you registered in the APIs console, and the error is indicating that you haven't done that or you haven't done it correctly.
To get the redirect URI from console:
Go to the console for your project and look under API Access.
Open Credentials section (in left side)
You should see your client ID & secret there, along with there is a
list of redirect URIs. If you want to change it or it was wrong,
click edit settings and modify.
Even if your redirect uri is properly set in the console, a lot of times, when you've recently changed settings in the google dev console, it will still tell you there's a redirect mismatch. It's a surprisingly common occurrence.
You can try...
Waiting; some have had luck with this, indicating that google takes some amount of time to register recent changes.
If you don't mind reconfiguring your app, creating a new client id in the google dev console tends to fix this problem with consistent results.