Is there an API to access all site data on all domains from a chrome extension (or firefox addin)?
Full story: I want to create a pseudo profile switcher, as an alternative to google's Google's "multiple sign-in". It will basically help user to switch between profiles that are created inside my extension. Right now, it is only a cookie-switcher because it can only access cookies (just like this extension: Swap My Cookies).
For creating a new profile (inside my extension) it saves all cookies in JSON format in filesystem and then deletes all cookies in browser, just like chrome's new profile. To switch between two profiles, it saves current cookies, clears cookies, and loads cookies for target profile. Note that I am not accessing chrome's actual profiles at all, and I am certainly not reading cookies from chrome's other profiles. This is just a pseudo profile switcher. Many websites are not working as they should work, because these websites store more things than just cookies. Is there a way to access all site data, and not just cookies? I have been working with chromium so far, but for this I am ready to switch to firefox or any other browser.
Following is picture of url chrome://settings/cookies after clearing all cookies using chrome extension API, how do I access the rest of data?
Image showing site data other than cookies
I want to create a pseudo profile switcher
For Firefox there is a per-tab container API under development which may pretty much provide what you want.
Related
On mid-2022 Google plans to disable third party cookies by default.
My use with 3rd party cookies is through google chrome extension (not for ads service)
I use an Iframe to translate some words on the document.
It looks something like this:
I have a chrome extension that loads an Iframe (In red)
The Iframe (in green) is under my domain x.com (i wish)
Each request that goes from my iframe client to the server is attaching cookie, but from mid-2022 it will be blocked due to chrome policy change and considering that the cookies are 3rd party
I have tried to find solution for this,
All I have found for now is TheTradeDesk Unified ID 2.0 but it will not help me since it's not store value / jwt (its anonymous id)
But could't find any other solution
Any ideas how to handle this?Thanks in advance.
We're also facing something similar, where we noticed if you have your browser configured to block 3rd party cookies, functionality regarding authentication did not work.
This afternoon, we followed a hunch to try and see if the setting to block 3rd party cookies also has an effect on an extension's background page (we're still using manifest v2). And turns out, it is not. So even with 3rd party cookies being blocked, requests made from the extension's background page can still use them.
Not sure if this is by design or a bug. And we still need to investigate how this works with manifest v3.
But hope this helps!
A good news is that Google keeps postponing the timeline for removing 3rd party cookies from Chrome. Right now (Dec 2022) it's planned for the second half of 2024 (https://blog.google/products/chrome/update-testing-privacy-sandbox-web/).
Eventually, we'll need a workaround, though. As #schmkr mentioned, Chrome extension's own code (background page / service worker, and iframes sources from the embedded HTML via chrome://... URLs) are not considered 3rd party. So there are two workarounds:
Pack your iframe app (html/js) as a part of the chrome extension instead of loading it from the external website (x.com in your example).
Keep the iframe app externally sourced, but change its logic. It should not send XHR/Fetch requests any more. Instead it should ask the extension background page / service worker to do that (using the messaging API).
I currently have a web app made in node.js. One feature of this app is to take notes. I want to provide the user with a way to browse the internet and select a text to add as a note in our web app without having to manually copy-pasting from one browser window to our app.
I know I can do this relatively simply using a Chrome extension that would be linked to the user account and would save the note to the database. However, I cannot use this approach since not all my users can install Google Chrome.
Therefore, I am looking for a way to browse the web from inside our web app. For example, it could be in an iFrame where we display a complete browser. That way, the user could navigate the web for information from inside the app, select text to save and click on a button (probably located outside the iFrame browser) to save the selected text as a note in our database.
How can I achieve such a thing in node.js ?
This is, essentially, impossible.
For you to get any data about the site the user was browsing you could either:
Restrict them to browsing sites willing to partner with you to give you permission to access their data via postMessage (a technical change on their part to work around the Same Origin Policy)
Proxy every request through your server which would:
Have large bandwidth requirements
Require a lot of rewriting of URLs (including dynamically generated ones in JS)
Require rewriting of X-Frames-Options and Access-Control-Allow-Origin headers
Need users who would trust you with all the data you passed through your system (including their passwords to third party sites)
Not work for Intranet sites (since your server could not reach them)
If I write a chrome extension, it normally consist of multiple parts:
One is the devtools page which is a normal HTML page with origin set to
"chrome-extension://<guid>/filename". On that page I can use
the Dropbox API to get user confirmation via HTML popup and then use
the saved auth info and do all work via the Dropbox javascript library.
Another part of extension is the content script which is executed
in the context of specified third-party web pages ("injected") and have
origin cookies and web storage shared with them.
Is it possible to also use the Dropbox JavaScript library in that content script?
I can't call authenticate in interactive mode since it will re-ask for confirmation for each different webpage I'm injected into. And calling authenticate without interactive will fail since the content script doesn't share the origin, cookies and web storage with the devtools extension page :(. Maybe there's some way to "pass" the Dropbox auth info from the part of the extension that offers GUI and where user successfully confirms dropbox usage to the parts of the extension that are GUI-less, like content script or background page?
I have managed to get Facebook working from code injected into a web app via a content script. I suspect there are multiple ways, but what I did was take advantage of the chrome.identity API to do the OAuth work for me, specifically the launchWebAuthFlow().
This can only be done in the background page (in my case an event page), but I send messages to the event page which replies with the access_token, which can then be used in URLs in the same was as the 'web' technique - i.e. in HTTP requests with XHR.
You can send/receive messages via the content script (using events on document), but I decided to do it directly using "external" messages with the chrome.runtime.sendMessage() API in the web app context, and chrome.runtime.onMessageExternal() in the background script. This requires adding "matches" for the URLs you're injecting code into in an "externally_connectable" section of the manifest.json.
I believe this can be adapted to make it work with Dropbox.
In a Google Chrome extension, is it possible to use localStorage and indexedDb to store data independently of the visited website? And if so, is it possible to store it even after the browser has been closed?
For an example, the user would save a text in the extension when visiting www.site1.com, browse and/or close Google Chrome, then access its data again on www.site2.com.
Yes. It is possible. I am currently working on an extension which saves the data using indexed DB. You can store the data on the background page, i.e. background page should contain scripts to create, retrieve and delete the data. Data can be send to background page using content scripts.
The new Facebook Javascript SDK can let any website login as a Facebook user and fetch data of a user...
So it will be, www.example.com including some Javascript from Facebook, but as I recall, that script is considered to be of the origin of www.example.com and cannot fetch data from facebook.com, because it is a violation of the "same origin policy". Isn't that correct? If so, how does the script fetch data?
From here: https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript
The same origin policy prevents a
document or script loaded from one
origin from getting or setting
properties of a document from another
origin. This policy dates all the way
back to Netscape Navigator 2.0.
and explained slightly differently here: http://docs.sun.com/source/816-6409-10/sec.htm
The same origin policy works as
follows: when loading a document from
one origin, a script loaded from a
different origin cannot get or set
specific properties of specific
browser and HTML objects in a window
or frame (see Table 14.2).
The Facebook script is not attempting to interact with script from your domain or reading DOM objects. It's just going to do its own post to Facebook. It gets yous site name, not by interacting with your page, or script from your site, but because the script itself that is generated when you fill out the form to get the "like" button. I registered a site named "http://www.bogussite.com" and got the code to put on my website. The first think in this code was
iframe src="http://www.facebook.com/plugins/like.php?href=http%3A%2F%2Fwww.bogussite.com&
so the script is clearly getting your site info by hard-coded URL parameters in the link to the iFrame.
Facebook's website is by far not alone in having you use scripts hosted on their servers. There are plenty of other scripts that work this way.. All of the Google APIs, for example, including Google Gears, Google Analytics, etc require you to use a script hosted on their server. Just last week, while I was trying to figure out how to do geolocation for our store finder for a mobile-friendly web app, I found a whole slew of geolocation services that had you use scripts hosted on their servers, rather than copying the script to your server.
I think, but am not sure, that they use the iframe method. At least the cross domain receiver and xfbml stuff for canvas apps uses that. Basically the javascript on your page creates an iframe within the facebook.com domain. That iframe then has permission to do whatever it needs with facebook. Communication back with the parent can be done with one of several methods, for example the url hash. But I'm not sure which if any method they use for that part.
If I recall, they use script tag insertion. So when a JS SDK call needs to call out to Facebook, it inserts a <script src="http://graph.facebook.com/whatever?params...&callback=some_function script tag into the current document. Then Facebook returns the data in JSON format as some_function({...}) where the actual data is inside the ... . This results in the function some_function being called in the origin of example.com using data from graph.facebook.com.