On 03/03/2022 08:52, Vilnis Termanis wrote:
Hi Andy,
Is it because of UI+admin that you are using Fuseki Webapp? Nothing else?
No, I'm only using the metrics right now and actually technically none
of the admin API commands (even though I enquired about them).
Which parts of Shiro are you using?
Only (static) basic auth against dataset endpoints, to "duplicate"
what Jetty auth does in Fuseki-Main out of the box (i.e. for a
principal to be passed on to fuseki-access).
and Shiro can be plugged in to Fuseki Main.
Thank you - that's good to know.
The Metrics API is in Fuseki Main
Great - I completely missed that. (It's obvious now that I've looked again.)
Fuseki Main where the requirement was a server for a cloud environment
So, looking at the the pom for server (compared to main), the only
real addition is jena-text from what I can tell. Is this a historic
thing (since Fuseki Main presumably is newer) or is there another
reason to (right now) pick server over main, other than having
full-text indexing available?
If it is the metrics net API, you wanted, then no, there is no reason to
not to use Fuseki main.
jena-text is in both. mvn dependency:tree
It is a dependency of jena-fuseki-webapp and that is pakaged by both
jena-fuseki-fulljar and jena-fuseki-war. jena-fuseki-fulljar is
currently the fuseki-server in the zip file.
jena-fuseki-server is packaging Fuseki main.
Andy
Two character change hopefully :-)
Indeed - but Ubuntu 20.04 packaged maven is old (3.6.3) - so I
hesitated before installing a standalone one :-)
Regards,
Vilnis
On Wed, 2 Mar 2022 at 16:59, Andy Seaborne <a...@apache.org> wrote:
Hi Vilnis,
Is it because of UI+admin that you are using Fuseki Webapp? Nothing else?
The Metrics API is in Fuseki Main.
--ping Enable /$/ping
--stats Enable /$/stats
--metrics Enable /$/metrics
and Shiro can be plugged in to Fuseki Main.
https://lists.apache.org/thread/q37s6kb3vy0ff6qbbrqy44qvbx8lojkq
Which parts of Shiro are you using?
(the multiple build warnings seem to be just warnings. Apparently, Shiro
2.0 fixes them.)
Slowly, Fuseki is moving towards being Fuseki Main + modules [1].
https://jena.apache.org/documentation/fuseki2/fuseki-modules.html
which is how I'm adding data-level security.
webapps are rather inconvenient because they are sealed by design and
intent. It's tricky to drop-in jena-permissions for example, if you
chose to use that, or control jena-fuseki-access.
Fuseki as a war file isn't going away.
It would be good to hear why people use WAR files so nothing gets missed.
In the modern IT infrastructure webapps add complexity so they need to
add something of use. Fuseki is already not using much of web.xml
dispatch because the set of names is dynamic, and web.xml is a fixed setup.
Then there are containers. "localhost" means something else in
containers so for admin access control, it needs shiro.ini and that's
fixed (pretty much for a container or and quite strongly for Tomcat/war).
jena-fuseki-fulljar will be Fuseki Main + a configuration that has the
same functions as today.
> (I was hoping to continue to use the admin
> API functionality & metrics - which are available e.g. with
> jena-fuseki-fulljar.)
Two, or more, such modules will be "UI" and "admin". It is also a good
moment to revised "admin" to split into its components (dataset
add/delete, compact/backup, stats/metrics), and also to simplify it with
a focus on configuration file configuration suitable for DevOps tools.
> Are there reasons why fuseki-access is being kept out of the
> webapp-enabled projects?
The original development was specifically for Fuseki Main where the
requirement was a server for a cloud environment. UI not required, admin
not allowed. It is managed configuration files.
Andy
This is not a plan.
A plan = a goal + a timescale + resources.
> (I've done my testing only against 4.3.2 because I haven't had a
> chance to update my maven version yet.)
Two character change hopefully :-)
On 02/03/2022 00:35, Vilnis Termanis wrote:
Hi,
I've been looking at Fuseki's Data Access control feature and
discovered that whilst it works with jena-fuseki-server (with Jetty
auth), it's not supported by jena-fuseki-fulljar (or anything with
jena-fuseki-webapp with shiro).
Adding fuseki-access as a dependency to fuseki-webapp does result in
the associated configuration being parsed but they are not enforced.
Upon closer inspection it would appear that the loaded configuration
is not applied. If I pinch a bit of logic from fuseki-main, it seems
to work as intended:
https://github.com/apache/jena/compare/jena-4.3.2...vtermanis:vt-try-graph-acl
(I've done my testing only against 4.3.2 because I haven't had a
chance to update my maven version yet.)
Are there reasons why fuseki-access is being kept out of the
webapp-enabled projects? (I was hoping to continue to use the admin
APi functionality & metrics - which are available e.g. with
fuseki-fulljar.)
If not, are there additional changes required before it could be
considered for inclusion in fusekii-webapp?
Regards,
Vilnis
