After reviewing the Permissions code I find an issue that I am not sure how to resolve.
There are a number of methods in SecuredGraph that can throw the current AccessDeniedException which extends RuntimeException. I suppose I can create an AccessDeniedRuntime exception so that I can throw it from methods like Graph.find() where a ReadDeniedException would be appropriate. I don't want to force massive exception processing changes on the rest of the code. If anyone has a suggestion I would like to hear it. Claude On Mon, Jul 13, 2015 at 1:00 PM, Claude Warren <[email protected]> wrote: > That sounds reasonable. > > So what we would have is > {noformat} > OperationDeniedException > | > AccessDeniedException > | > > +----------------------------+------------------------+--------------------------+ > | | | > | > AddDeniedException DeleteDeniedException > UpdatedeniedException ReadDeniedException > > {noformat} > > Claude > > On Mon, Jul 13, 2015 at 12:26 PM, Andy Seaborne <[email protected]> wrote: > >> On 13/07/15 12:03, Claude Warren wrote: >> >>> I would like to rename the UpdateDeniedException to >>> AccessDeniedException. >>> AddDeniedException, DeleteDeniedException currently extend it. >>> >>> jena-permissions will then extend that to create: >>> ReadDeniedException -- for read restrictions >>> UpdateDeniedException -- for update restrictions (modifying triples that >>> already exists as opposed to adding new triples) >>> >>> I think that this will allow Fuskei to properly respond to the case where >>> jena-permissions is in place and there are update restrictions in place. >>> Currently Fuseki returns this as a 500 error. Once we have a common >>> permission denied exception we can return either authentication required >>> or >>> access denied as appropriate. >>> >>> Thoughts? >>> Claude >>> >>> >> I agree that the existing name isn't so good nowadays. >> >> I wonder if "access" is best reserved for permissions exceptions and have >> a bland "can't do that" to cover both access denied situations and >> operartion not appropriate (delete from a append-only or read-only graph). >> >> How about "OperationDeniedException" as the root of all refusals, then >> AccessDeniedException used as the root of all permissions exceptions >> (whether defined in jena-permission or just this top level one in jena-core >> and all subclasses with meaning in jena-permission). >> >> Then Fuseki can catch AccessDeniedException and respond with 401,403 and >> still have different handling for non-permissions related exceptions (e.g. >> 400 Bad Request for update a read-only graph where other parts of a >> datasets are mutable). >> >> Andy >> >> > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
