Seems to me that Graph.remove( node, node, node) should also throw a DeleteDeniedException.
On Mon, Jul 13, 2015 at 9:52 PM, Claude Warren <[email protected]> wrote: > 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 > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
