You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Claude Warren <cl...@xenei.com> on 2015/07/13 13:03:38 UTC
proposal: rename UpdateDeniedException
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 like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: proposal: rename UpdateDeniedException
Posted by Claude Warren <cl...@xenei.com>.
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 <cl...@xenei.com> 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 <cl...@xenei.com> 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 <an...@apache.org> 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
Re: proposal: rename UpdateDeniedException
Posted by Claude Warren <cl...@xenei.com>.
DOH! I didn't follow the chain far enough up the list. I see now that
JenaException extends RuntimeException..... problem solved.
On Mon, Jul 13, 2015 at 10:45 PM, Andy Seaborne <an...@apache.org> wrote:
> On 13/07/15 21:52, Claude Warren 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
>> AccessDeniedExceptionwhich extends RuntimeException.
>>
>
> Why not extend JenaException? Or OperationDeniedException?
>
> 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.
>>
>
> Yes.
>
> I think the choice of exceptions names/types will be down to the
> permissions code which is, architecturally, another graph implementation.
> An implementation can introduce it's own exceptions to reflect it's own
> facilities. It isn't going to be documented in the Graph interface when
> there are SecuredGraph specifics involved.
>
> As now any operation in Graph can potentially throw a runtime exception,
> logically add/delete could have their "throws" removed. They are an
> artifact of one point-of-view really.
>
> 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
>>
>>
>> AccessDeniedException
>>
>> On Mon, Jul 13, 2015 at 1:00 PM, Claude Warren <cl...@xenei.com> 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 <an...@apache.org> 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
Re: proposal: rename UpdateDeniedException
Posted by Andy Seaborne <an...@apache.org>.
On 13/07/15 21:52, Claude Warren 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
> AccessDeniedExceptionwhich extends RuntimeException.
Why not extend JenaException? Or OperationDeniedException?
> 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.
Yes.
I think the choice of exceptions names/types will be down to the
permissions code which is, architecturally, another graph
implementation. An implementation can introduce it's own exceptions to
reflect it's own facilities. It isn't going to be documented in the
Graph interface when there are SecuredGraph specifics involved.
As now any operation in Graph can potentially throw a runtime exception,
logically add/delete could have their "throws" removed. They are an
artifact of one point-of-view really.
> 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
>
>
> AccessDeniedException
> On Mon, Jul 13, 2015 at 1:00 PM, Claude Warren <cl...@xenei.com> 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 <an...@apache.org> 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
>>
>
>
>
Re: proposal: rename UpdateDeniedException
Posted by Claude Warren <cl...@xenei.com>.
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 <cl...@xenei.com> 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 <an...@apache.org> 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
Re: proposal: rename UpdateDeniedException
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@apache.org> 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
Re: proposal: rename UpdateDeniedException
Posted by Andy Seaborne <an...@apache.org>.
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