Http_open/3

General
1

Hi,

Does http_open/3 work with swish ?

:- use_module(library(http/http_open)).
?- http_open('https://www.google.fr',S,[]).
No permission to call sandboxed `'$current_module'(_1680,_1682)'
Reachable from:
	  system:'$file_type_extensions'(A,B)
	  system:absolute_file_name(A,B,C)
	  '$syspreds':absolute_file_name(A,B,C)
	  '$syspreds':exists_source(A,B)
	  http_open:exists_source(A)
	  http_open:autoload_https(A)
	  http_open(A,B,C)
2

No. Anything with explicit streams does not work as we cannot guarantee users properly clean these. You can use load_html/3. See SWISH -- SWI-Prolog for SHaring for a demo (near the end of the page).

3

Ok thank you Jan.
I have actually noticed that there are several “sandbox restrictions” when using swish.
If I program in python using Jupyter or Colab, I have no such restrictions. So are these restrictions due to the inherent nature of Prolog or do they come from the technology used to develop swish which is different from Jupyter?

4

These restrictions come with the design. Roughly, there are two options: (1) have a stand-alone frontend and backend where the backend runs in some OS sandbox or (2) do the whole thing in one process.

If we do (1), we have less sandbox restrictions. SWISH however uses the design (2). It is a monolithic Prolog process where a user task is executed inside a fairly isolated environment inside the process: a thread for the execution and a temporary module for the code. We must ensure that the user program cannot break out of this confinement and the execution doesn’t leave any permanent traces. This is done by constructing the reachable call tree from the original goal and compare that to a whitelist. After the query completes, the module is destroyed and the thread terminates.

This is related to the non-educational use case for SWISH: allow multiple people to work concurrently on shared data. So, we create a SWISH instance with a lot of data (pre)loaded (linked data, Prolog data, access to databases, etc.) and allow people to write (analysis) programs for that and share these.

But, if you wanted to, you could redesign SWISH to split the frontend and the backend into two processes that communicate over a network. Then place the backend in a sandbox (e.g., virtual machine, docker image, chroot jail, …) and fork the backend to create user-specific backends. That would allow lifting most of the sandbox restrictions. We use this architecture to provide access to R from SWISH.

That would also allow to have stateful interaction, although I still think that has at least as many disadvantages as advantages.

Note that you can also use the browser version at SWI-Prolog WebAssembly build test. That has other limitations. It does preserve state and can do unrestricted meta programming, and allows for arbitrary global changes to the system.

1 Like
6

Thank you Jan for this extensive answer.

I know about swi-prolog wasm but I love swish. It is so convenient for teaching and learning Prolog.