incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henry Story (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CLEREZZA-447) GraphNode not appropriate object to send from JSR311 code to Renderlet
Date Sun, 27 Feb 2011 18:37:37 GMT

    [ https://issues.apache.org/jira/browse/CLEREZZA-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000026#comment-13000026
] 

Henry Story commented on CLEREZZA-447:
--------------------------------------

> A few remarks:
> - which renderlet is chosen is not random but bases on the type-priority list

I had assumed that. But what if the foaf file your server picked up remotely at <https://bblfish.net/user/admin/people>
contained information of the form

@prefix : <http://clerezza.org/2009/03/controlpanel#>

<http://reto.name/user/admin/profile> a :ProfileViewerPage

and when your JSR311 method builds the MGraph it adds

<http://reto.name/user/admin/profile> a :ProfilePage

So then the MGraph returned contains

<http://reto.name/user/admin/profile> a :ProfileViewerPage, :ProfilePage

Then at that point how would the system know which of the renderlets too choose? It could
be random it seems to me

>  a graphnode is to respond an arbitrary resource describe by the graphnode
> when returning a graph (or mgraph) the typerendering system isn't called

What it the meaning of the code 
resultNode.addProperty(RDF.`type`, PLATFORM.HeadedPage) 
resultNode.addProperty(RDF.`type`, CONTROLPANEL.ProfileViewerPage) 

It seems to me that it is so that the typerendering system can choose the correct renderer.
I could not find any other way of infuencing the choise
of the rendered. You seem to confirm this in your next point

> the reason for the typerenderin system is that this allows selection of renderlet based
on the rdf type rather than java-type

so when you say

> you can return arbitrary object and use mbw for rendering them (default jax-rs way)

that of course makes sense. What I am suggesting is that one may need to return at least two
graphs. One based on trusted data about the content,
the other based on the content itself. The trusted graph could also be a bunch of java objects,
if retuning such small graphs is thought to be a bit too heavy.

- i don't see a security problem: the client needs read right to any of the triple collections
in a graphnode, how this data is rendered to non-rdf formats is the business of the delivering
instance, not the producer of the data. A renderlet cannot (at least shouln't)access more
data than what the client could also get when requesting rdf.

the security issue comes because of the potentially random behavior described above. The content
of what someone untrusted says seems to be able to determine the logic of content published
by the system. 

- Only admins can read the system graph, so this is not returned with normal requests

Perhaps one should not return a system graph, but a metadata graph. It is what the owner of
the resource believes *about* the content graph, that should determine how it is rendered,
not the content of the graph - or if it is the distinction must be possible to make.

- there is a semantic difference between say a skos:Concept and the page on which the foaf-topic
is shown, only the latter could well be a :HeadedPage
- in your example you would most likely get a security exception, because its unlikely the
client has the right to add those triples. A get-request shouldn't have any side-effect, so
no triples should be added (except of course to a graph that isn't stored)

I don't get a security exception in my code.

- in the general case the resource <http://foo/s?q=http://ex.org/bar> is distinct from
<http://ex.org/bar>. The first is controlled by foo, the root resource should add triples
too the first one (when generating a response graph on the fly).

Ok. Perhaps this is where I am confused: how does the JSR311 code then pass the graph of <http://ex.org/bar>
to the renderlet? Can the renderlet fetch that graph itself?
If not it has to place the content of <http://ex.org/bar>  into the graph it sends back.
That is where type confusion may step in.

- you shouldn't add triples to tell the system what to do (assuming this is what you mean
by "routing information"), rather you should add triples that are true about the requested
resource and the system should do the best given this facts and the client request. (Its app
to the application to decide in what world of evaluation the triples have to be true).

I want to display a remote profile locally in a human readable way, so the user can decide
if the remote user is his friend. I don't want to make decisions in the renderlet on what
relations are important or what ontologies should be used, as I would like to leave that to
the UI folks to work on. Neither I nor the user know ahead of time what is true of the remote
resources. That is what the point of displaying the information is for, so that a human can
make a decision: Friend or not friend? ...

I may well have missed something of course being new to the platform. 



> GraphNode not appropriate object to send from JSR311 code to Renderlet
> ----------------------------------------------------------------------
>
>                 Key: CLEREZZA-447
>                 URL: https://issues.apache.org/jira/browse/CLEREZZA-447
>             Project: Clerezza
>          Issue Type: Bug
>            Reporter: Henry Story
>
> The main reason for Clerezza (zz) having an RDF engine is so that one can fetch data
off the web and use it to guide the logic of what is going on.
> When that is done one has to carefully distinguish what is said or believed by different
parts of the engine. *Who* believes *what*, is very important, 
> and not making that distinction will create security holes. 
> So for example the following is problematic. When a @GET annotated method returns a GraphNode
in a JSR311 class one has to add information to 
> that returned GraphNode that is going to decide which Renderlet gets called next. Something
like
> 		resultNode.addProperty(RDF.`type`, PLATFORM.HeadedPage)
> 		resultNode.addProperty(RDF.`type`, CONTROLPANEL.ProfileViewerPage)
> But what if the JSR wants to return a graph that is not controlled by the System? What
if it wants to return a graph found on the internet in order to display it.
> It would have to write something like  this:
> 	@GET
> 	def viewPerson(@Context uriInfo: UriInfo, @QueryParam("uri") uri: UriRef): GraphNode
= {
> 		val foaf: GraphNode = descriptionProvider.getWebDescription(uri, Cache.Fetch)
> 		val resultNode: GraphNode = new GraphNode(new UriRef(uriInfo.getAbsolutePath.toString),foaf.getGraph)
> 		resultNode.addProperty(RDF.`type`, PLATFORM.HeadedPage)
> 		resultNode.addProperty(RDF.`type`, CONTROLPANEL.ProfileViewerPage)
> 	   return result
> 	}
> But now it has mixed system information with remote information. This means that if the
foaf profile contained some different type information, perhaps set
> by a different instance of Clerezza, the ZZ instance will be randomly selecting one of
many Renderlets, some of which were not chosen locally. This will completely
> confuse the display logic in the system.
>   Such a JSR 311 method must instead return a more complex object, consisting of a system
graph perhaps and a content graph. The System graph is the only one that should be 
> considered for routing information. 

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message