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 <[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
