I have an iframe that is embedded on external websites.
That iframe performs some actions that require to record some cookies, one of them is login the user on the iframe source website.
I basically followed this: https://webkit.org/blog/8124/introducing-storage-access-api/
It worked but only when you use Safari on an incognito window when I try to do the same using a common tab the cookies are not stored.
UPDATE:
We found a workaround is not the best in the world but something is something.
We added a CNAME on the external website CNAME: example.externalwebsite.com -> example.com
We changed the iframe src=example.externalwebsite.com
In this scenario, the subdomain example.externalwebsite.com is able to set the cookie as usual.
GOOD PART: we found a way to make it work.
BAD PART: we had to ask any client to add the CNAME and update their websites to change the iframe sources but as I said something is something.
Related
I have an IFrame on my webapp which host a website.
The hosted website needs access to local storage (cookies) to get the auth token.
On Chrome all is working fine, but going into incognito mode gives me an error, because 3 parties are blocked.
Disabling this option in settings is not an option for me - I just can't force a users to do that.
Is there anything I can do to go around this problem?
The hosted website is the website I trust and I know the URL. I was thinking maybe I can add something to the header to allow access only from that URL, something Like CORS?
Thanks for help.
I am writing a mobile web page which has both a redirect and two manual backup links (for when the redirect doesn't work) to a Facebook Page.
The link takes the form:
fb://page/[PAGE ID NUMBER]
The redirect and link work in Chrome Mobile and Firefox Mobile but (surprise) they don't work in Facebook Browser which, instead, gives me the error:
Page can't be loaded.
I am perplexed that a link to the Facebook App doesn't work from within the Facebook Browser.
How can I resolve this? Are there any creative solutions or workarounds... or have I missed something obvious?
Additional Info: It looks like the redirect is working in at least one version of the Facebook Browser on the Facebook iOS App. So the issue may be isolated to the Facebook Android App.
UPDATE 1
I've made some progress. I've discovered that Facebook's in-app browser doesn't always (or doesn't ever?) acknowledge / load / execute external script files.
Added: (To find out why not, see Update 8, below...)
In this case the href attributes in the links were being re-populated with fb:// protocol links by an external script after page load.
I have moved the relevant javascript functions from the external script to the bottom of the actual page. I have tested the functions and I can see they are now activating. Although the links still don't work.
UPDATE 2
It struck me that there may be some security mechanism going on behind the scenes which doesn't allow for any javascript-driven re-population of href attributes and that instead of the fb:// protocol links not working, it was maybe the case that the initial, default http://www.facebook.com/ links were never even being replaced and it was those http:// protocol links that weren't working.
So I updated the PHP template, so that the initial default links were the fb:// instead of the http:// links (so nothing in the page delivered to the Facebook in-app browser would need to be updated by any client-side script at all at any point).
Nope. Still not working.
UPDATE 3
I added a plain vanilla link to the bottom of the page, linking to the site's homepage. The link functioned entirely normally.
Later, I pointed the original links to an external domain. They didn't work.
So... I concluded that only http:// protocol links to the same domain would work and that's why the links wouldn't work if they pointed to an external domain or to an fb:// protocol address.
Wrong conclusion.
I pointed the original links at the site's homepage and they still didn't work.
UPDATE 4
In a moment of inspiration, I removed the reference to the external script which I'd set up to customise the links to the OS + browser environment (even though this script reference was being entirely ignored by Facebook, according to the FB Debugging tool.
The links worked.
So the reason why the plain vanilla link I had added earlier had worked, was nothing to do with where it was pointing and simply to do with the fact that at no point had a script tried to access it or update it.
Added: (This isn't the reason. See Update 8, below...)
I pointed the original links at the external domain. They worked.
I pointed the original links at the fb:// protocol. They didn't work.
UPDATE 5
Now that I've got rid of the external script reference, I can point the original protocol links at any http:// protocol address and they work.
Including the http://www.facebook.com web equivalent of the page I am trying to open in the Facebook App.
Let's review that:
The Facebook website is opening in the Facebook in-app browser.
I know, right?
UPDATE 6 [.HTACCESS REDIRECT]
I changed the link destination to /fb-custom-redirect/.
Then I added a line to the mod_rewrite section of my .htaccess file:
RewriteRule ^fb-custom-redirect fb://page/[PAGE ID NUMBER]
Naturally the server didn't understand what I was asking for.
UPDATE 7 [PHP REDIRECT]
I created an index.php for /fb-custom-redirect/ and added the following:
<?php
header('Location: fb://page/[PAGE ID NUMBER]');
?>
Guess what? This works in Firefox Mobile. It also works in Chrome Mobile.
But in the Facebook in-app browser, it returns the same error:
Page can't be loaded.
UPDATE 8
I've only just discovered - and this is not insignificant - that when the Facebook Debugger Tool (https://developers.facebook.com/tools/debug/sharing/) refreshes Facebook's cache of a given page, it only refreshes the .html.
Pressing Scrape Again does not refresh any external resources like .css and .js files.
Instead Facebook continues to refer to its own cached versions of those files, regardless that the .html file cache has just been updated.
The workaround (in PHP, at least) is to append the filepath with a new, randomly generated query string every time the page is loaded:
<link rel="stylesheet" href="/styles/mystyles.css?'.uniqid().'" />
Now the Facebook in-app browser is fetching up-to-date versions of my .css and .js files.
This explains my initial observation in Update 1:
I've made some progress. I've discovered that Facebook's in-app
browser doesn't always (or doesn't ever?) acknowledge / load / execute
external script files.
I'm going to conclude that the Facebook in-app browser was parsing the external .js file reference every time, but it was repeatedly accessing an old, cached version of that file.
Nevertheless, even after all the hypotheses and experimenting above, I'm still no closer to discovering why fb: protocol deeplinks don't work in the Facebook App's in-app browser.
I give up.
Apple apps are sandboxed. This means they cannot access other apps and execute code. Facebook is running a browsing instance and when you try to call the fb:// protocol, the iPhone is blocking you from doing this to try to create an infinite app loading loop. I.e, you open a page in FB browser and it opens itself in FB browser and it opens itself in FB browser...
I need to know how some softwares or programs inject html,css,js into webbrowser without installing any extension. once I open chrome or firefox I find ads on google homepage, facebook, youtube ... I need to know how they inject this, how to prevent it and how to know which program did it.
Here is my google home page on chrome
and all the extensions are disabled I even deleted most of them
What worries me the most, is that in google chrome devtool (ressources) the url of the displayed image is the same url of the google logo. when I enter this url I found the real logo of google
You have a computer virus somewhere affecting you.
Edit:
Multiple things could be happening:
Something is intercepting the network request and injecting a different image.
Something has replace your version of chrome with their own version. The base code is public and their version can do whatever they want.
keep in mind, that content de-facing might happen on the Router/Proxy level, too.
some routers have content filters and domain blacklists for child protection.
maybe it's some kind of joke on the router level, where someone added
a content replace filter.
check your computer (spybot + kaspersky)
check your router
check firewall and all networking filters in the chain
I noticed that after you log into google.com/analytics, and see 'in page' feature, after you enter your own domain, you see the same report.
How do they know? as there are different domains. The cookie solution is not a choice as the logging in is done on google.com and the overlay is shown on own domain. There is absolutely no logging in on own domain.
Does the javascript on my domain set a cookie?
Thanks
I just checked and for me it loaded it in an iframe
Edit
Ok got it to load in the whole site, looks like it adds in a bunch of stuff on the url hash
example.com/page#gaso=pNl50_ygxyusFT6rXNNxTiQk2j7Qorb_ygw6EbrhHRD4Z8eX12C8tn5DaTqIoevkeUiDDSP4aLsYc9.sRMQO9II5Ii_zuKJ7un2DQ
Looks like they use CrossDomainChannel so the cross origin iframes can talk.
"A communication channel between two documents from different domains."
http://closure-library.googlecode.com/svn/!svn/bc/4/trunk/closure/goog/docs/closure_goog_net_xpc_crosspagechannel.js.source.html
I used something similar - here is a jQuery version in case you're interested
http://benalman.com/projects/jquery-postmessage-plugin/
If you have a cookie set for google.com and you load foo.com in your browser with a <script src="http://google.com/xxx></script> in the HTML, your browser will send the google.com cookie when fetching that script.
If you've used Google Wave or iGoogle you have probably seen that you can insert widgets that are made by third parties without approval. My question is: How does prevent the widge from performing XSS or steak cookies? Are the widgets loaded in an <iframe>? If yes, then what prevents them from redirecting you to another page?
Thanks
Yes, they use iframes to host the untrusted content. They cannot steal cookies because this content is hosted on a different domain (gmodules.com), and the browser prevents cross-domain interaction.
Regarding redirection, a module hosted in an iframe CAN change the window.location (but surprisingly, cannot read it). So, it is possible for malicious code in a user-uploaded module to take you to a spoofed google login page in an attempt to steal your password.
I assume it is because those widgets would be banned if they did so.
The HTML5 group is working on a real(technical, rather than legal) solution to this problem using the "sandbox" attribute in iframes.
They can redirect you to another page, as far as i know.