XForms interoperability and security

Hi,

I am still trying to assimilate all the consequences of the long and
interesting thread we had yesterday with Erik and the comment of Alex
about interoperability...

We've already discussed that and I know that a part of the vision is
that OPS should let us deploy applications that are "XForms ready", ie
that work with today's browsers that don't support XForms but can also
talk XForms with XForms enabled devices.

What I don't know is how far we are from this vision with OPS 3.0 and
what are the consequences on our practices.

Catching up with Alex' comment yesterday, if we want to write
interoperable forms, we should probably avoid using the oxf: protocol in
URIs within XForms documents, such as in:

  <xforms:instance id="xml" src="oxf:/examples/xml-to-url/sample.xml"/>

That means also that we should probably differentiate in our page flows
the pages that serve XForms pages from the pages that serve instance
documents.

While serving XForms pages, we could send raw XForms to devices that
support it and XHTML or HTML to other devices.

The pages that serve instance documents could make good use of the
different HTTP methods to support read (GET), new (POST), write (PUT)
and delete (DELETE) operations.

What are the others good practices that may facilitate this transition
to client side XForms?

That brings a question about the security of these methods when using
the AJAX based proxy mechanism implemented by OPS 3.0.

When I define a page that will take care of updating an instance, I may
want to define permissions on that page.

If I use the ACL mechanisms implemented by my HTTP server and/or servlet
container, will they be taken into account?

Lets say for instance that I want to give write permissions to existing
users from my local network (checking the TCP/IP addresses).

Will these permissions be checked in both modes?

In "optimized mode" where there is no physical HTTP access to the page,
do the methods you are using to forward the request check the
permissions?

In "physical mode" where you are sending an actual HTTP POST, do you
behave as a real proxy and do you keep enough of the HTTP headers from
the request that you have received so that the credentials and TCP/IP
address from the browser can be checked?

Also, how would that work on top of HTTPS?

This is of course only an example and there might be other consequences
that are not exposed by this example!

Thanks,

Eric

--
Freelance consulting and training.
                                            http://dyomedea.com/english/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Eric van der Vlist wrote:

 > We've already discussed that and I know that a part of the vision is
 > that OPS should let us deploy applications that are "XForms ready",
 > ie that work with today's browsers that don't support XForms but can
 > also talk XForms with XForms enabled devices.

Yes!

 > What I don't know is how far we are from this vision with OPS 3.0
 > and what are the consequences on our practices.

 > While serving XForms pages, we could send raw XForms to devices that
 > support it and XHTML or HTML to other devices.

Absolutely, and that's easy to do in the epilogue.

 > The pages that serve instance documents could make good use of the
 > different HTTP methods to support read (GET), new (POST), write (PUT)
 > and delete (DELETE) operations.
 >
 > What are the others good practices that may facilitate this transition
 > to client side XForms?

Besides URLs, questions of styling come to mind. For example,
currently OPS does not support XForms pseudo-classes. We have been
thinking about rewriting CSS to support those, but that's not done
yet.

The truth is that there is not much hindsight yet on this subject. In
the fairly near future, once people start actually using different
implementations to run their XForms code, we will get a better overall
picture.

 > That brings a question about the security of these methods when using
 > the AJAX based proxy mechanism implemented by OPS 3.0.
 >
 > When I define a page that will take care of updating an instance, I may
 > want to define permissions on that page.
 >
 > If I use the ACL mechanisms implemented by my HTTP server and/or servlet
 > container, will they be taken into account?

 > Lets say for instance that I want to give write permissions to existing
 > users from my local network (checking the TCP/IP addresses).
 >
 > Will these permissions be checked in both modes?

When doing an XForms submit with replace="instance", the originator of
the request is always OPS, not the browser. So it's always going to be
the IP of the machine running OPS.

 > In "optimized mode" where there is no physical HTTP access to the
 > page, do the methods you are using to forward the request check the
 > permissions?

I could almost have bet that with a RequestDispatcher, this wouldn't
be the case, but I can't find the reference in the Servlet spec at the
moment. The bottom line is that probably not, but that has to be
checked.

 > In "physical mode" where you are sending an actual HTTP POST, do you
 > behave as a real proxy and do you keep enough of the HTTP headers
 > from the request that you have received so that the credentials and
 > TCP/IP address from the browser can be checked?

No, we don't really act as a proxy and we don't forward anything in
that direction. What should we actually forward? I don't think you
could solve the issue of the IP address, could you? There may be
something to improve here, so let us know if you have some ideas on
the subject.

 > Also, how would that work on top of HTTPS?

That would work just fine I think ;-) But a client certificate
wouldn't work, obviously.

 > This is of course only an example and there might be other consequences
 > that are not exposed by this example!

Very good points!

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws