On 14 January 2011 12:00, Christoph Helma <helma at in-silico.ch> wrote:

>
> > Actually, it's not that bad from security point of view, because the REST
> > framework will handle the extensions itself and adding an extension is
> > merely a configuration issue.
> >
> > But you are at the mercy of the framework, and here I understand these
> > differ. The Ruby framework as explained in Christoph's email works via
> URI
> > rewriting, while Restlet works via "tunneling", i.e. rerouting the
> request
> > to the proper code, rather than rewriting the URI.  Thus in Restlet we
> end
> > in the proper code to handle the request, but with the original URI . And
> if
> > we want to check if the URI is authorized by the OpenSSO server, we have
> to
> > do the extension removing ourselves :(
> >
>
> Please don't get me wrong: I see the extension variant purely as a
> convenience method for GET requests of text oriented clients and html
> links (there is no point in using them in POST requests).




> If it is too
> hard to implement them in a safe way in one of the frameworks I would
> rather use a more inconvenient method than to risk that extensions end
> up as resource URIs (or to spend too much efforts to make it work).
>


OK, we can handle this in Restlet. If accessing
http://host:8080/ambit2/dataset/1.rdf

getRequest().getOriginalRef()  returns http://host:8080/ambit2/dataset/1.rdf

getRequest().getRequestRef()  returns http://host:8080/ambit2/dataset/1


> Maybe we can work for some time with the current implementations and
> choose another solution if we run into troubles.
>
>
I'm fine with the current implementation, as long as the URIs with
extensions don't get into RDF representation and can be handled by AA in a
uniform manner, without requiring registering additional policies .

Extensions are switched on within our services, please report anything that
doesn't behave as it should.

Best regards,
Nina


> Best regards,
> Christoph
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>