[
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
