Keep in mind that you can wire up your endpoints just as you like: https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html
including multiple endpoints for any given service and so on. ajs6f > On Jul 19, 2018, at 8:08 AM, Andy Seaborne <[email protected]> wrote: > > > > On 18/07/18 18:53, Dan Pritts wrote: >> I use shiro.ini as follows. I did this so I could have our monitoring >> system do queries, while our primary consumer software had full privileges. >> I presume, but honestly don't know for sure, that the /foo/query URL >> allows queries only. > > It does - if you use a service name /query (and the config does not wire that > to.say, update :-) then the request goes to the query action handler which > only groks SPARQL queries and can't go to anything else. > > Andy > >> Note that the write_user needs to have both reader_role and writer_role. >> # Licensed under the terms of http://www.apache.org/licenses/LICENSE-2.0 >> [main] >> # we aren't using TLS because we are proxied by apache which handles that >> for us >> ssl.enabled = false >> # a simple sha256 is adequate for this internal-only usage >> # to do better, look at https://shiro.apache.org/command-line-hasher.html >> credentialsMatcher = >> org.apache.shiro.authc.credential.Sha256CredentialsMatcher >> #iniRealm=org.apache.shiro.realm.text.IniRealm >> iniRealm.credentialsMatcher = $credentialsMatcher >> [users] >> # adding users here implicitly adds "iniRealm = >> org.apache.shiro.realm.text.IniRealm" >> # to get the sha hash: >> # echo -n "passwordhere" | sha256sum # but watch out, the password is in >> your shell history now! >> # the -n is important, otherwise you'll get a newline. >> # or get the Shiro Hasher tool >> write_user=shasumhere,reader_role,writer_role >> read_user=shasumhere,reader_role >> # roles that you implicitly created in the users section don't necessarily >> need to be listed here >> [roles] >> # this is a "first match wins" config. >> [urls] >> ## Control functions open to anyone >> /$/stats = anon >> /$/server = anon >> /$/ping = anon >> /fcrepo/query = authcBasic, roles[reader_role] >> /** = authcBasic, roles[writer_role] >> Andy Seaborne wrote on 7/17/18 12:32 PM: >>> Hi there, >>> >>> > More concretely my question is, are PUT, POST, and DELETE requests >>> > considered "administrative" functions? >>> >>> Admin operations are HTTP requests to the UI - the URLs start "/$/" not the >>> graph management PUT, POST, and DELETE requests of SPARQL Graph Store >>> Protocol (and the dataset URL also respects plain REST PUT, POST). >>> >>> SPARQL Query can be over POST - large queries can be over the practical >>> limits of HTTP GET and POST allows a query of any size to be set. >>> >>> If you want detailed control, you can do some configuration by using the >>> built-in Apache Shiro but it can be easier to put the Fuseki server behind >>> a reverse proxy (Apache httpd, nginx, ...) because these systems have more >>> detailed and sophisticated permissions control systems including load >>> control. >>> >>> Or run in Apache Tomcat as a WAR and use Tomcat controls. >>> >>> >>> Andy >>> >>> Apache Shiro + REST >>> https://stackoverflow.com/questions/41918916/apache-shiro-http-method-level-permission >>> >>> >>> On 17/07/18 11:20, Jeffrey C. Witt wrote: >>>> I was reading this security documentation ( >>>> https://jena.apache.org/documentation/fuseki2/fuseki-security.html) today >>>> and had a small question. >>>> >>>> Basically, I would like be able to make PUT, POST, DELETE requests from >>>> localhost, while restricting public access to the SPARQL endpoint (requests >>>> NOT originating from localhost) to GET only requests. >>>> >>>> My question is whether according to the above documentation that is the >>>> default configuration. >>>> >>>> The docs say: >>>> >>>> "In its default configuration, SPARQL endpoints are open to the public but >>>> administrative functions are limited to localhost." >>>> >>>> More concretely my question is, are PUT, POST, and DELETE requests >>>> considered "administrative" functions? >>>> >>>> Thanks >>>> jw >>>> >> -- >> Dan Pritts >> ICPSR Computing & Network Services >> University of Michigan >> <https://www.postbox-inc.com>
