Develop Reference

Google Sign-In API Hang with uncaught error Failed to get parent origin from URL hash

I'm using Google Sign-In JavaScript client for months without problem.
But recently when user tapping on sign in button from webapp that added to homescreen, the signin pop-up just hang without showing any content.
When debugged via remote debugging, an error is displayed in console pane:
Uncaught Failed to get parent origin from URL hash!
originated from 4188232449-v2-idpiframe.js:136 (javascript loaded internally by google library).
I'm sure it's not programming/config error since the same webapp was previously working for months without problem, and I haven't modified any code.
I've tried google search for this particular problem and browse Google documentation for any recent changes in Google Sign-In API without any luck.
Is it bug from Google API Javascript client library, glitch from recent Chrome browser update on Android, or there is some changes in API usage that I doesn't yet aware?
Library used is https://apis.google.com/js/platform.js
This is init param for gapi.auth2.init():
{
client_id: GAPI_CID, // defined as constant
cookiepolicy: 'single_host_origin',
prompt: 'select_account',
ux_mode: 'popup',
fetch_basic_profile: true
}
Any insight will be much appreciated. Thank you.
P.S.: This problem is different with Uncaught Failed to get parent origin from URL hash since on that case the problem is caused by misconfiguration of required credential in Google API console.
If you never had succedded in integrating sign-in flow with your app, perhaps answer from that post can help you.
Otherwise, if you have had successfully integrated sign-in flow for some time but recently problem suddenly/erratically appears with symptom of blank screen on popped-up window, than you have same problem with me.

I can confirm we are experiencing the same problems at my company since recently. It seems a bit erratic, not 100% of the time. But for some users, some time, they are met with an empty sign-in popup with the url pointing to "https://accounts.google.com/o/oauth2/iframe" but nothing happens.

Not a complete answer yet, but this may be a reasonable workaround for some. I updated the ux_mode to use redirect and it is partially working now.
auth2 = gapi.auth2.init({
client_id: '1234.apps.googleusercontent.com',
scope: 'profile email',
ux_mode: 'redirect',
redirect_uri: 'https://blahblah.io/oauth2callback'
})
NOTE: it seems redirect_uri is required, contrary to Google's docs. This isn't a perfect drop-in replacement, but it solves the "URL hash!" error
This blog post and the Git Repo in it could also be helpful for anyone attempting to use redirect

My electron app started to fail today for the same reason. Been debugging quite a lot and I think found the reason, but don't know how to solve it, why it happened, or if it is electron or google's fault.
In my electron app, I have 2 webviews, one for the main content and another one for google popup dialogs.
So when google needs to open the authentication, it generates this IFRAME:
<iframe id="ssIFrame_google"
sandbox="allow-scripts allow-same-origin" aria-hidden="true"
src="https://accounts.google.com/o/oauth2/iframe#origin=https%3A%2F%2Fxxxx.com&rpcToken=dxxd318480305.4777704"
style="... display: none;"></iframe>
Mind that the URL has HASH parameters: your origin and the token.
However, when on the electron side I capture the new-window event in order to open the URL myself in another webview, the event I receive LACKS the hash parameters:
event {
type : "new-window",
url:"https://accounts.google.com/o/oauth2/iframe",
.
.
}
So what google's iframe is complaining about (I debugged it) is exactly that it can't find the origin and rpctoken parameters that should be in the hash parameters.
For a reason I don't understand (I haven't updated electron) the new-window event does not receive the full url anymore.
Using #howMuchCheeseIsTooMuchCheese answer below I have changed the flow to use the redirect callback, then capture that callback myself and restart the application. It is not ideal, but at least I can login into my applications.

Soundcloud auth popup callback.html never closes after connecting

I'm using Soundclouds JS sample code for client side JS apps to connect with the Soundcloud API, as a start. The only difference between their code and mine is I've put in my own client_id and redirect_uri. (I also copied their callback.html, put it on my server, put its address in the soundcloud page for my app).
After ok-ing with my popup blocker, the auth popup comes up and asks permission to access my account, I give it permission, then the popup clears all previous content and simply informs: 'This popup should automatically close in a few seconds' - but it doesn't, and the rest of the code that shows its past authorization never displays.
Here is Soundclouds sample that I'm using. I've tried it while using a server on localhost and also deploying it and changing redirect_uri appropriately with the exact same results.
SC.initialize({
client_id: 'YOUR_CLIENT_ID', // changed it to mine
redirect_uri: 'http://example.com/callback'
});
SC.connect().then(function() {
return SC.get('/me');
}).then(function(me) {
alert('Hello, ' + me.username);
});
Looking in the dev console on both Chrome and Firefox, I dont see any errors. I've also made sure the protocol for my redirect_uri file matches between my account settings and the code.
Does the 'Website of your app' field on the Soundcloud page for my app make a difference? I tried setting it, it didnt fix it. What does client secret do?
The closest to an answer I've found so far is from this SO page where it seems he found out that you can't use an url that doesn't start with 'www.' ??? Its hard for me to believe that this is the problem and unfortunately for me neither localhost or my domain start with www.
Thanks in advance for any help.

In your callback.html, change the line:
<body onload="window.opener.setTimeout(window.opener.SC.connectCallback, 1)">
to:
<body onload="window.setTimeout(window.opener.SC.connectCallback, 1)">
In your application setup page at soundcloud.com, ensure your website setting and callback uri are on the same domain (whether that is localhost or the production domain) and all should work.
Note: for debugging, comment out this line to leave the popup there deliberately, then console can be used to interrogate other code in the callback.html page.

Facebook app browser debugging [duplicate]

I'm developing website with a lot of HTML5 and CSS3 features. I'm also using iframe to embed several content on my website. It works fine if I open it using Chrome/Firefox/Safari mobile browser. However, if I share on facebook (post/page) and I opened it up with Facebook application with Facebook Internal Browser, my website is messed up.
Is there any tools or way to debug on Facebook Browser? Thanks.

This is how you can do the debugging yourself. It's painful, but the only way I've come across so far.
tl;dr Get the Facebook App loading a page on your local server so you can iterate quickly. Then print debug statements directly to the page until you figure out what is going on.
Get a link to a page on your local server that you can access on your mobile device (test in mobile safari that it works). See this to find out your local IP address How do you access a website running on localhost from iPhone browser. It will look something like this
http://192.xxx.1.127:3000/facebook-test
Post that link on your Facebook page (you can make it private so your friends aren't all like WTF?)
Click the posted link in the Facebook mobile App and it will open up in Facebook's mobile browser
Since you don't have a console, you basically need to print debug statements directly to the page so it is visible. Put debug statements all over your code. If your problems are primarily related to CSS, then you can iteratively comment out stuff until you've found the issue(s) or print the relevant CSS attributes using JavaScript. Eg something like (using JQuery)
function debug(str){$('body').append("<br>"+str);}
Quite possibly the most painful part. The Facebook browser caches very aggressively. If you are making changes and nothing has happened, it's because the content is cached. You can sometimes resolve this by updating the URLs, eg /facebook-test-1, /facebook-test-2, or adding dummy parameters eg /facebook-test?dummy=1. But if the changes are in external css or js sheets it sometimes will still cache. To 100% clear the cache, delete the Facebook App from your mobile device and reinstall.

The internal browser the Facebook app uses is essentially a uiWebView. Paul Irish has made a simple iOS app that lets you load any URL into a uiWebView which you then can debug using Safari's Developer Tools.
https://github.com/paulirish/iOS-WebView-App

I found a way how to debug it easier. You will need to install the Ghostlab app (You have a 7-day free trial there, however it's totally worth paying for).
In Ghostlab, add the website address (or a localhost address) you want to debug and start the session.
Ghostlab will generate a link for access.
Copy that link and post it on Facebook (as a private post)
Open the link on mobile and that's it! Ghostlab will identify you once you open that link, and will allow you to debug the page.
For debugging, you will have all the same tools as in the Chrome devtools (how cool is that!). For example, you can tweak CSS and see the changes applied live.

If you want to debug a possible error, you can try to catch it and display it.
Put this at the very top of your code:
window.onerror = function (msg, url, lineNo, columnNo, error) {
var string = msg.toLowerCase();
var substring = "script error";
if (string.indexOf(substring) > -1){
alert('Script Error: See Browser Console for Detail');
} else {
var message = [
'Message: ' + msg,
'URL: ' + url,
'Line: ' + lineNo,
'Column: ' + columnNo,
'Error object: ' + JSON.stringify(error)
].join(' - ');
alert(message);
}
}
(Source: MDN)
This will catch and alert your errors.
Share a link on Facebook (privately), or send yourself a message on Facebook Messenger (easier). To break the cache, create a new URL every time, e.g. by appending a random string to the URL.
Follow the link and see if you can find any errors.

With help of ngrok create temporary http & https adress instead of your ordinary localhost:3000(or other port) and you could run your app on any devices. It is super easy to use.
and as it was written above all other useful information you should write somewhere inside div element (in case of React I recommend to put onClick on that div with force update or other function for getting info, sometimes it helps because JS in FB could be executed erlier than your information appears). Keep in mind that alerts are not reliable, sometimes they are blocked
bonus from ngrok that in console you will see which files was
requested and response code (it will replace lack of network tab)
and about iFrame.If you use it on other domain and you rely on cookies - you should know that facebook in-app browser blocks 3rd party cookies
test on Android and iOS separately because technicaly they use different browsers

A couple of requests with user# in URL lead to "Policy breach notice" from Google AdSense

I've recently got an email from Google, saying that they are going to ban my AdSense account because I'm sending Personally Identifiable Information to them with my Google AdSense tag requests. It says that around 1% of requests from my website have a referrer of:
some_user#my_website.com/some/subpage
and they consider some_user#my_website.com to be PII (even though it can be completely made up abcd1234#my_website.com). More on this here: https://support.google.com/adsense/answer/6163366?hl=en .
I never link to this kind of URLs (the only form I use is my_website.com/some/subpage), but I guess my users sometimes enter it manually (since product-wise my website is providing an email service, it may seem reasonable by some logic).
I figured URI of some_user#my_website.com/some/subpage is legal since http basic auth allows for specifying user like this. When I entered it manually to Firefox, some_user# disappears from the location bar but in the Net panel of Firebug I can see all files are indeed requested from some_user#my_website.com/some/subpage and that's how Google sees it too.
I though that as a brute-force solution even something like:
if uri contains '#':
redirect to my_website.com
would do.
I'm using NGINX/UWSGI/Python Paste + JS. I've tried to implement the above condition both on server side and in JS, but my URI always says my_website.com/some/subpage even if I manually put some_user#my_website.com/some/subpage in the browser address bar.
I've also tried configuring basic_auth in NGINX to disallow providing any user but with no effect.
How do I get rid of these requests?
How do I get the FULL URI (with some_user#) in JS? I tried document.URI and window.location.href but they didn't contain the user part...

Apparently presence of user# part in the URI can be detected by examining window.location.href. I haven't noticed it before since window.location.href only contains user# in Webkit-based browsers (e.g. Chrome, Opera, Safari) but not in Firefox!
To resolve the problem I've added a check on that in JS + a JS redirect to an URL without user[:password]#.
Hopefully Google uses the same variable to figure out referrer for the ad requests, so it get PII only from Webkit browsers & fixing it for Webkit suffices. Will keep you posted.

How to write the js for a chrome extension that blocks a specific site

I've spent a good few hours trying to crack this myself, having analysed a bunch of other people's work (this is the latest one I've tried to hack Block URL with a specific word somewhere in the subdomain ), and have come up none the wiser.
I feel like the js shouldn't really be that complex, I'm just trying to block a webpage and surface an error message in its place.
This is where I've netted out atm:
chrome.declarativeWebRequest.onRequest.addRules({
id: 'some rule id',
conditions: [
new chrome.declarativeWebRequest.RequestMatcher({
url: {
host: 'www.dailymail.com'
}
})
],
actions: [
new chrome.declarativeWebRequest.CancelRequest()
]
});

The answer at Block URL with a specific word somewhere in the subdomain works as expected. When it does not work, follow the following steps to troubleshoot the problem:
Open the background page's console and look for error messages.
Search for the error message on Google, and try to understand the recommended results. Trustworthy sources include Stack Overflow, the extension documentation, Chromium's bug tracker, the chromium-extensions and chromium-apps mailing lists.
Check whether you have added the correct permissions to your manifest file.
If you have just added the new permissions, make sure that you have reloaded the extension (e.g. by clicking on Reload at chrome://extensions/).
With the information you've provided, I can think of three reasons for failure:
Are you using Chromium beta, Chromium dev (or even Canary)? If not, then either install Chrome from one of these channels, or use the webRequest API instead. The declarativeWebRequest API is currently not available on the stable channel, only on the beta and developer channels.
url is an object of the type UrlFilter. There is no property called "host", if you want to match an exact host, use hostEquals, like this:
url: {
hostEquals: 'www.dailymail.com'
}
You have not added the correct permissions. To get your demo to work, you need to declare the declarativeWebRequest and *://www.dailymail.com/* permissions in the manifest file.