Page 1 of 1
Posted: 15 Jul 2020, 02:16
I'm trying to understand the configuration property "deployment.assumeFileSystemInCodebase". This /configuration page says "Defines if files from the local filesystem are always handled as if they would be part of the codebase."
I don't really understand this. In my experience, all of the files needed to run a WebStart app are listed in the jnlp file and downloaded from the trusted host defined in the jnlp file. When/how would there be local files that need to be made part of an app's codebase?
Posted: 15 Jul 2020, 08:17
more information about the property and behaviour: https://github.com/karakun/OpenWebStart/issues/106
Posted: 16 Jul 2020, 00:43
Hmm thanks for the link, but I'm afraid I still do not understand. Does this option make a local jnlp file become trusted?
If so, how else does OWS work if it cannot trust a local jnlp? I ask because (with older or more lenient browsers) using the old Java WebStart, the browser plugin could invoke Java WebStart directly; it was not necessary for the user to download and then double-click on the downloaded jnlp file.
Now that browser plugins are no longer used, it is my belief that OWS can only activate against jnlp files that have been downloaded and double-clicked by the user. Perhaps I am ignorant and there is another use case?
It seems likely that I am still misunderstanding the "assumeFileSystemInCodebase" setting
Posted: 16 Jul 2020, 01:19
Peeking at the IcedTea-Web code, it looks like "assumeFileSystemInCodebase" setting allows you to specify "file://" urls in the jnlp and to treat those resources as secure (as if they came from the trusted codebase). Is this correct?
Posted: 17 Jul 2020, 23:41
Yes this setting you are looking for
Posted: 21 Jul 2020, 05:56
Thanks. FYI we do not use this "local file" capability, we just wanted to be clear on its functionality. which you've clarified. Seems a bit dodgy to trust local content IMO