When clicking on the Continue With Google button, a popup appears (on my website that I created using Django in Python) as expected in Google Chrome asking which account to continue with etc...
By doing the same thing in Microsoft Edge, the popup is blank, there is no content. I'm not sure if it's a problem with my code, my OAUTH account or Microsoft Edge itself.
This is the popup in Google Chrome (working as normally)
This is the popup in Microsoft Edge (not working at all)
I expect the top image to be happening in both browsers.
Does anyone have any idea why this isn't working in Microsoft Edge?
EDIT:
The following two errors appear in the Microsoft Edge console but they also show up in Google Chrome:
Failed to load resource: the server responded with a status of 400 ()
[GSI_LOGGER]: The given origin is not allowed for the given client ID.
I tested the website in Firefox and everything works as expected similar to Google Chrome.
Why is Edge the only browser that isn't working (My Microsoft Edge is up to date)
HTML Code:
<script src="https://accounts.google.com/gsi/client" async defer></script>
<div id="g_id_onload"
data-client_id="**********.apps.googleusercontent.com"
data-login_uri="http://localhost:8000/accounts/continue-with-google/?source=signup"
data-auto_prompt="false">
</div>
<div id="continueWithGoogleButton" class="g_id_signin"
data-type="standard"
data-size="large"
data-theme="outline"
data-text="continue_with"
data-shape="pill"
data-logo_alignment="left"
data-width="300">
</div>
Be sure to read this, because it seems that might be causing the issue (blank window). Also, the key points are important (#2, and #3), since you're developing in localhost. This would also mean that you might need to add (if you don't have it already) a meta tag regarding the referrer policy.
This was answered in the comments by FiddlingAway. I wanted to post this as an answer to make it clearer for future references. To save a bit of research, in Django, you'll need to write in settings.py file SECURE_CROSS_ORIGIN_OPENER_POLICY = "same-origin-allow-popups". Check the above links to find out what this means.
Hope this helps!
Related
The following code shows an <iframe sandbox... pointing to a page that opens a test websocket with a message on successful open. It works correctly on Chrome and Edge printing the It worked! message immediately.
On Firefox it fails with Uncaught DOMException: The operation is insecure. and no further reasoning.
<!DOCTYPE html>
<html lang="en">
<body>
<iframe
sandbox="allow-scripts"
src="https://firefox-wss-example.tiiny.site/"></iframe>
</body>
</html>
The linked websocket page source code is simply as follows:
<!DOCTYPE html>
<html lang="en">
<body>
<script>
const ws = new WebSocket('wss://demo.piesocket.com/v3/channel_1?notify_self');
ws.addEventListener('open', () => {
console.log('It worked!');
});
</script>
</body>
</html>
I have tried a mixture of wss:// and ws://, as well as permissive CORS headers, but none of my attempts fix the issue on Firefox despite having an appropriate setup. I am starting to think this is a Firefox 97 bug but am unsure of how to verify.
Why does this snippet work on most browsers but fails on Firefox?
I've been through this before, spend weeks on investigations, what I found is: Firefox runs sandboxed JavaScript under the blob:// protocol, and you're only allowed to upgrade to WebSocket from http:// and https:// connections. blob:// isn't either.
Although it's not very clear in their documentation, you may take a look into the websocket upgrade implementation as well as in this issue about CSP inheritance to understand it better, but it's basically the way Firefox have chosen to implement Sandboxing.
We never found a workaround for this, the only way was to drop the Sandboxing, or drop Firefox support for this specific feature.
On the other hand, Chromium based browsers saves the script file locally (I cannot say with 100% of confidence if it is stored in a temporary directory or virtual file system), and still uses the http:// protocol to access them, this way you can upgrade to ws:// or wss://. Those browsers may also inherit CSP, since they keeps the opener instance.
Edit: This problem is not tied to an specific Firefox version, it has been implemented this way for a long time. I has been 5 or 6 releases from the time I went into this problem, it still this way, and will probably stay this way, it's not considered a bug and it's not close to a highly requested feature.
In order to triage a problem with a web browser I am trying to determine the initiator of the XXX-xsrfstatemanager.js file (the XXX part seems to be something dynamic like a nonce) that occurs as part of a Google Authentication flow (using OAuth).
When I use Chrome developer tools, it says the below URL is the initiator:
https://accounts.google.com/o/oauth2/v2/auth?approval_state=%21Ch[REDACTED]Q%E2%88%99AJ[REDACTED]xq&as=-aBk[REDACTED]
Looking at the result of the above page see a lot of Javascript, but the string "xsrfstatemanager" is nowhere to be found, nor do I see any other javascript pages being included. Unless there is some really cryptic code that is somehow building this URL, the call is actually coming from some other page.
Does anyone know how I can get the 'real' initiator? Or if the above URL might be correct, if I can get more information like what exact line number of the file initiated the call?
By the way, while I edited the above URL for security reasons, if you go to (for example) www.quora.com and quick "continue with google" it is easy to see the flow in question.
The flow includes a redirection, which is why you cannot see the source code that initiates/references that script.
If you view the source of the original URL that is opened when you click on "Continue with Google", you will see the <script src> that references it. This works in Chrome and probably Safari -
view-source:https://accounts.google.com/o/oauth2/auth?redirect_uri=storagerelay%3A%2F%2Fhttps%2Fwww.quora.com%3Fid%3Dauth488109&response_type=code%20permission%20id_token&scope=email%20profile%20openid&openid.realm=&client_id=917071888555.apps.googleusercontent.com&ss_domain=https%3A%2F%2Fwww.quora.com&access_type=offline&include_granted_scopes=true&prompt=select_account&origin=https%3A%2F%2Fwww.quora.com&gsiwebsdk=2
From the source code -
<script src='https://ssl.gstatic.com/accounts/o/532969778-xsrfstatemanager.js' nonce="IgiKmQiLZIHDwGvce7/q6Q"></script>
You can also use tools like Fiddler to see the source code of the redirect, or check "Preserve log" in the Network panel of the Developer Tools feature of Chrome, or by going to the original URL with JavaScript disabled.
MS CRM 2011 on premise.
No problems if accessed via internal address: crm:5555
Go to crm.ourcompany.co.uk:5555 in IE and load account page and the ribbon is totally grey. (Not disabled - every pixel is the colour grey.)
In Chrome and Firefox the ribbon is loaded fine.
Browser console in IE, Chrome and FF all say access errors.
I can see they are trying to access crm:5555.
IE says:
SCRIPT5: Access is denied.
PageLoader.js, line 1 character 1226
The second line above is presented as a link. Clicking it shows me this: http://pastebin.com/bBadk9HS
The full path is http://crm.ourcompany.co.uk:5555/_static/_common/scripts/PageLoader.js?ver=-1056260279
P.S. IE is "Browser Mode: IE10 Document Mode: IE9 standards".
After Long investigation I have found out the reason for same issue like this.
We had previous rollup activity feed solution.
After importing the new version of Activity feeds this hectic issue was sorted out.
Activity feed new solution is available with rollup up package.it can be found by exacting the rollup package. Previously this was available in Microsoft Dynamic market place.
It turns out that the problem is an address lookup plugin on the Account form.
This is trying to access http://crm:1999, which is a 404, and http://crm:5555, which isn't allowed.
Solutions are to fix the server on http://crm:1999 and set up proper managed internal and external URLs so it'll know whether http://crm:5555 or http://crm.ourcompany.co.uk:5555 or remove the plugin.
I am using the sharer button inside a facebook app. It works in all browsers except Chrome.
docs.google.com/open?id=0B4wxEQ6Do659WmcwdkN5VlFDZ2s
I check tools->javascript console and I see that I have a warning:
[blocked] The page at https://mywebsite.com ran insecure content
from http://static.ak.fbcdn.net/connect.php/js/FB.Share.
The code used in this button is:
<a name="fb_share" type="button" share_url="http://mywebsite.com" href="http://www.facebook.com/sharer.php">Share</a><script src="http://static.ak.fbcdn.net/connect.php/js/FB.Share" type="text/javascript"></script>
Googled it, Stackoverflowed it but nothing helpful out there.
This is because, your site is using https protocol, but since that script is on http, chrome thinks this is a security issue.
Use https version of the file which is located at: https://facebook.com/connect.php/js/FB.Share
and you should be fine.
I am getting (NS_ERROR_DOCUMENT_NOT_CACHED) error when I try to access the Javascript code through firefox.I get this error in the contents tab of HTTPFOX.
I googled and set the parameters of browser in config file as specified in this site but it still doesn't work.
http://code.google.com/p/httpfox/issues/detail?id=20
Can somebody suggest whats going wrong since the same code works fine for safari browser..
If anyone is interested in a solution to this, I believe it's to do with the plugin noscript. Disabling it fixed this, but I have yet to work out what part of noscript was causing the issue. Will update if I find out.
Edit:My issues was with a twitter auth callback. In the Advanced settings of noscript under ABE, in the SYSTEM ruleset, on the line "Accept from LOCAL" I added "*.twitter.com". This allowed callback requests from *twitter.com to return to a local address.
On my macbook I had to uninstall firefox completely to correctly get the content of an ajax response with httpfox. This also implies to remove the firefox profile bij removing this Firefox folder (I could only find it via the terminal and not via Finder):
/Users/<YOURUSER>/Library/Application Support/Firefox
Then install firefox again and install the httpfox add-on.
I tried many cache settings also by entering about:config in the firefox URL however without succes. Be aware that removing the profile settings like I describe will also remove all your personal firefox customization. It concerned firefox 18.0.2 and httpfox 0.8.11.
We used to get the same error when our JavaScript made an XMLHTTPRequest to the server. On the server side, we had java, and the java response, the content type was not explicitly set to "text/html". When that was done
resp.setContentType("text/html");
the error went away.