On 06/11/13 17:26, Ian Dickinson wrote:
...
OK, first issue: currently, we have the notion that the management
capability should be available as a separate endpoint, serving JSON.
This is so that both the new UI, and also command-line scripts and
build automation tools can drive the Fuseki management functions. At
present, the defaults are:
* normal access to Fuseki (queries, etc) on port 3030
* management access (updates, dataset revision, config) on port 3131
I just tripped over the fact that Javascript served in a page from
http://host:3030 can't access the API at http://host:3131 unless a
cross-domain policy is added to host:3131. And even then we will have
problems with Internet Explorer pre- version 10 and CORS, though there
are workarounds for this.
An alternative is to put the management API on a path on host:3030(*)
that is unlikely to be the name of an actual dataset, for example '$'
or '_mgmt'. One consideration is that we anticipate users wanting to
have different access control rules for the query and admin
interfaces, so that e.g. adding and deleting datasets requires
password access. I don't know enough about Java web containers, or
using Apache/nginx as a front-end proxy to a web container, to know
whether one or other of these choices would be easier to administer
from an access & authorisation point-of-view.
Ian
[1] https://issues.apache.org/jira/browse/JENA-420
(*) or whichever port Fuseki is running on
The port split isn't some deeply; it has been convenient because when
Fuseki is fronted by httpd/nginx, or on a system like AWS that blocks
requests by port, you can easily expose the query path and block the
admin operations.
If that convenience isn't turning out to be convenient, it gets changed.
There are a lot of different ways deployment might happen so -
anyone/everyone - what works well in the real world?
This relates to a WAR deployment - that would be easiest if there were
(logically) two webapps even though securing any private protocol will
be needed.
There are three categories of operations:
1/ interacting with datasets
2/ inspection of the server (read-only, meta requests)
3/ administation/change of the server
I have a mild preference for /$/ -- maybe 2 and 3 will need different
root names.
As a general style point, I prefer that the default setup is "safe" -
hence you have to turn updates on, rather than the default being updatable.
Andy
