Similar to this, but has more details.
"share"ing is expected to be done by one script.
"storage" is which GM_{g,s}etValue use.
"different websites" are those which have different origins.
My scheme now:
On website A, I insert an iframe of site B, and synchronize storage by postMessage.
Information I've got:
From this, it seems that Tampermonkey used to support share data cross-originly.
As mentioned by wOxxOm, in order for 2 domains to share data via GM storage API, the script must run on both e.g. via #match.
However, in Tampermonkey the domains will get access to the data at the time script was injected.
Update: As pointed out by wOxxOm, "Both Tampermonkey/Violentmonkey provide real-time access to the real values. They do it by propagating the change to all tabs/frames where this script instance runs."
You can also use GM_addValueChangeListener() to listen to changes to the storage.
GM_addValueChangeListener()
Adds a change listener to the storage and returns the listener ID.
'name' is the name of the observed variable.
The 'remote' argument of the callback function shows whether this value was modified from the instance of another tab (true) or within this script instance (false).
Therefore this functionality can be used by scripts of different browser tabs to communicate with each other.
Note: In Greasemonkey & FireMonkey, the asynchronous GM.getValue() would always get the current up-to-date data.
Related
Consider this scenario:
A content script wants to upload a file. I would prefer this operation to be done from my service/background script, but passing a File to that side via messages seems to be somewhat impossible without weird workarounds.
This is a good reference for the workarounds available: Passing FormData/File Object from content script to background script in chrome extension with Manifest V3
Workaround 1 seems bad, since it will require to break up the request which is not compatible with the backend API. Workaround 2 seems insecure, since the host web page will definitely be able to send rogue messages to an embedded iframe as it will share context.
I'm considering having the content script perform the upload directly like this:
The content script loads the authentication secret from extension storage (chrome.storage.sync or chrome.storage.local depending on login persistence mode).
It calls fetch directly to upload the form data.
Is that safe?
One hazard I had in mind was that a host page could hook window.fetch to intercept the credentials. That doesn't seem possible after my testing (the content script has a separate fetch defined in its own isolated environment). Is there anything else to watch out for?
I have a script that retrieves a webhook (meaning it has to be deployed as a publicly accessible App), and then uses an API to send a message.
The API requires using a key and secret, which I obviously don't want accessible to the public.
Q1: Is there a way to hide an API key/secret in another script and somehow have it accessible?
(Or any other similar solution - doesn't have to be fancy, just functional/safe).
Alternate Question:
Q2: What can a stranger actually see in my public Apps Script project? The full code? If I hide keys in a functions with an underscore ie. function name_(){}, can they read it?
IMPORTANT INFO: I have not 'shared' the project or spreadsheets with anyone, they're still private. But I've 'deployed' the Web App with permissions for 'anyone'. I assume that means anyone can access?
Everything in the script is visible to whoever has access (script owner, workspace admins, added users). Unless only the url of the webapp is shared and if the script itself is not shared then they are not able to access the script, so technically you can still keep them in your script. It is safe there and only the owner and workspace admins (if it is for Google workspace) can access it.
A way you can store/save the key is by storing it in script properties. Doing this you only need to run the script once to store the API key, moving forward you can remove the API key from the script and it will still run:
https://developers.google.com/apps-script/guides/properties#saving_data
Also refer to this post for more information, in my posted answer I have also provided alternatives and reference links:
Is it safe to put in secrets inside Google App Script code?
My project meet this issue, too. Because the amount of functions is not too much , So i hide my main GAS behind an dummy one .
So far I had 2 GAS
the main GAS with key , and all functions , and I deploy it as Web APP
Of cause u need doGet or doPost to do as entrance of API
The dummy one to share with users.
Then you can call something like below in dummy GAS
var url = 'https://script.google.com/macros/s/xxxxxxxxxxx/exec';
UrlFetchApp.fetch(url,{'method': 'get'});
I hope its useful in your case.
I have an extension which provides a number of services to any web app that requires them. I had been assuming that a web app could use chrome.runtime.sendMessage(ext-id,message), but when I try, there is no sendMessage function on chrome.runtime.
Have I misunderstood where sendMessage can be used, and is there another technique that I can use to communicate from an arbitrary web app to my extension?
There are a few options.
First, http://developer.chrome.com/extensions/manifest/externally_connectable.html is the closest to how you're thinking about it right now. You're expecting to be able to add proprietary, Chrome-specific functionality to arbitrary web pages. externally_connectable will give you a limited version of (see http://developer.chrome.com/extensions/messaging.html#external-webpage for an example), but only for specific web pages (e.g., *.yourdomain.com but not *.com).
Second, you can postMessage from your web page to a content script (see http://developer.chrome.com/extensions/content_scripts.html#host-page-communication), which can do anything a content script can. If you need chrome.* APIs at that point, you can message from the content script to your extension's page, which has access to any chrome.* APIs that it's asked for.
Finally, depending on what your "number of services" actually is, you can always executeScript another script directly into a target webpage, which is similar to forcing the webpage to include it as if it were another <script> tag. (Only similar to, not identical to, because the injection typically happens after the page has loaded.)
When I launch a RemoteApp via Remote Desktop Web Access, is there a way to send data to the remote app?
Desired senario:
A user logs into a website with their credentials. They also provide demographic information such as first name, last name, address, etc.
The website connects to the RemoteApp via SSO and makes the demographic information available to the RemoteApp.
For example, if the RemoteApp is a Windows Forms app, can I get this information and display it in a message box?
Edit1: TomTom's response in this question mentions using named pipes to send data. Is that applicable to this problem?
It turns out you can pass command line parameters to the RemoteApp using the remoteapplicationcmdline property like such:
remoteapplicationcmdline:s:/Parameter1: 5234 /Parameter2: true
(The names "/Parameter1" and "/Parameter2" are just examples. Your remote app will have to define and handle these as appropriate.)
This setting is part of the RdpFileContents property of the MsRdpClientShell object.
Here is a resource for other RdpFileContents properties.
Your code might end up looking something like this:
MsRdpClientShell.PublicMode = true;
MsRdpClientShell.RdpFileContents = 'redirectclipboard:i:1 redirectposdevices:i:0 remoteapplicationcmdline:s:/Parameter1: 5234 /Parameter2: true [Other properties here...]';
MsRdpClientShell.Launch();
For larger amounts of information, we might send preliminary data to a web service, retrieve an identifier back, pass this identifier to the RemoteApp via the command line, then have the RemoteApp query the web service to get all the information.
Of course, for the parameters to be of use the program must be looking for them. Setting up a database to query has a little security issue if it is sensitive data.
If the program (RemoteApp) is looking for data in the form of a CSV or table or something, then you might be able to send a lot of data to be processed. It just depends upon what parameters (and form) the program is going to use.
I have two scripts. I put them in the same namespace (the #namespace field).
I'd like them to interactive with another.
Specifically I want script A to set RunByDefault to 123. Have script B check if RunByDefault==123 or not and then have script A using a timeout or anything to call a function in script B.
How do I do this? I'd hate to merge the scripts.
The scripts cannot directly interact with each other and // #namespace is just to resolve script name conflicts. (That is, you can have 2 different scripts named "Link Remover", only if they have different namespaces.)
Separate scripts can swap information using:
Cookies -- works same-domain only
localStorage -- works same-domain only
Sending and receiving values via AJAX to a server that you control -- works cross-domain.
That's it.
Different running instances, of the same script, can swap information using GM_setValue() and GM_getValue(). This technique has the advantage of being cross-domain, easy, and invisible to the target web page(s).
See this working example of cross-tab communication in Tampermonkey.
On Chrome, and only Chrome, you might be able to use the non-standard FileSystem API to store data on a local file. But this would probably require the user to click for every transaction -- if it worked at all.
Another option is to write an extension (add-on) to act as a helper and do the file IO. You would interact with it via postMessage, usually.
In practice, I've never encountered a situation were it wasn't easier and cleaner to just merge any scripts that really need to share data.
Also, scripts cannot share code, but they can inject JS into the target page and both access that.
Finally, AFAICT, scripts always run sequentially, not in parallel. But you can control the execution order from the Manage User Scripts panel