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
