Closed Aradiv closed 4 years ago
@Aradiv old system was not possible to use for own plugins at all
@johnd0e i used the old system for own plugins all the time
Ok, but I need sample of such code.
example script that will alert "newToken" every second refresh
redacted.user.js.txt
Still, I do not see here secure way to operate data. Yes,, you avoid saving it to localStorage. But now you have to expose some unsecure function to retrieve that data.
redacted.user.js.txt
Still, I do not see here secure way to operate data. Yes,, you avoid saving it to localStorage. But now you have to expose some unsecure function to retrieve that data.
the token never needs to be retrieved outside the sandbox since all querys with the token are made inside of it. So unless you expose the getToken() function you can't retrieve the token outside of the plugin sandbox.
Let's begin from start: how do you put value into sandbox initially?
Is it just hardcoded like in redacted.user.js
?
Then it is not more secure than if you just hardcodes it in some local variable.
you could just window.prompt it
@Aradiv OK, that makes sense.
But still most applications I can ever imagine would require data exposition, in one or another way. E.g. earlier you suggested usage for tile layers apikeys. But after you initialize L.TileLayer - everyone can see it's properties, even private ones.
Well, you can implement own leaflet class, that will keep apikey hidden. But again, in some point you should use it in web request, which can hijacked by anyone (on your machine).
Because of such their nature api keys are designed not to keep top-secret data.
a lot of the map providers provide the ability to create short lived read only limited access tokens when you have a long live one. so exposing the short lived one is okay (sometimes you can even ip bind it) but you should never expose the long lived ones.
and if you do your requests from inside the sandbox it is still not visible to any other plugin
@Aradiv Really? I would like to see real samples if you have them (or when you will have, in the future).
In general, I agree that there can be some limited application for GM sandbox. But it's not for wide use.
You see my related PR, do if you want — feel free to test it, fix it, and improve it.
yes this is only usefull for things that interact with third party services and maybe some operation critic information that you want to have specially protected.
This discussion made me think that may be we can greatly simplify our wrapper code.
Following sample does not use script injection (continued in #358):
Update: this code does not actually work for GM
@johnd0e IMHO The window = unsafeWindow is not really a good idea Since you can't put code only in sandbox anymore.
Put except this it looks okay
Since you can't put code only in sandbox anymore.
Right. But we can fix that with #356
i need to place some code outside of wrapper() since i have various things running in GM sandbox that don't want to expose.
Functions that need to be accessible are placed inside wrapper everything else is outside wrapper
with the old build system i just placed the code before the @@PLUGINSTART@@ and could control where my code is running.