Re: [Xsltforms-support] cross-domain questions again

2016-10-11 Thread C. M. Sperberg-McQueen

> On Oct 10, 2016, at 6:23 AM, b...@shroggslodge.freeserve.co.uk wrote:
> 
> Hello xsltforms-support@
> 
> I think I understand correctly that it is not allowed to POST/PUT a resource 
> to a domain other than the one the xform was loaded from.
> 
> Is it possible to GET a resource from a different domain to the one the xform 
> was loaded from please?

If it is, I haven’t figured out how.  (There may be ways to set the
browser configuration to allow it, but I haven’t figured out how to do
it for myself, let alone explain to users what they would have to do.
You may have better luck in that regard.)

In my experience, dealing with the Same-Origin policy in the 
browser is one of the most challenging issues in deploying XForms
solutions.   (Challenging in part because it seems to be hard to 
get clear accurate information about what exactly browsers do 
and don’t allow, and challenging because for those not actively
engaged in security work the restrictions often appear arbitrary,
capricious, and unmotivated.  I have been told on good authority
that they really aren’t, but it’s hard to believe that, given that the
browser vendors don’t enforce similar constraints against
Javascript.)

What I end up doing is configuring Apache on my server to work
as a proxy server, and specifying in the .htaccess configuration
file for a particular directory that if the user requests resource
XYZ/W/VU.xml from that directory, the server should fetch
http://ww.otherserver.example.com/W/XYZ/VU.xml (or whatever)
and send it to the client.

In shared hosting environments, the service provider sometimes
won’t allow using Apache as a proxy; in that case, I write a simple
bash or PHP script to do essentially the same thing (taking care to
serve a clearly identified set of URIs from a clearly identified 
originating host, to try to minimize whatever security exposure there
is in such a proxy service).

I hope this helps. 


C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cms...@blackmesatech.com
http://www.blackmesatech.com



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Xsltforms-support mailing list
Xsltforms-support@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xsltforms-support


Re: [Xsltforms-support] cross-domain questions again

2016-10-11 Thread bch
Hi

Thank you for the response and the food for though it has provided
regarding the use of a proxy of some sort as a 'get around'.

After all this time, I would have thought that some progress would have
been made to allow cross-domain resource access that respects a balance of
functionality requirement and security. Perhaps it is a little more risky
and troublesome than I can imagine.

I will give your suggestion some thought. Thank you again.
Habs

On 10 October 2016 at 21:38, C. M. Sperberg-McQueen <
cms...@blackmesatech.com> wrote:

>
> > On Oct 10, 2016, at 6:23 AM, b...@shroggslodge.freeserve.co.uk wrote:
> >
> > Hello xsltforms-support@
> >
> > I think I understand correctly that it is not allowed to POST/PUT a
> resource to a domain other than the one the xform was loaded from.
> >
> > Is it possible to GET a resource from a different domain to the one the
> xform was loaded from please?
>
> If it is, I haven’t figured out how.  (There may be ways to set the
> browser configuration to allow it, but I haven’t figured out how to do
> it for myself, let alone explain to users what they would have to do.
> You may have better luck in that regard.)
>
> In my experience, dealing with the Same-Origin policy in the
> browser is one of the most challenging issues in deploying XForms
> solutions.   (Challenging in part because it seems to be hard to
> get clear accurate information about what exactly browsers do
> and don’t allow, and challenging because for those not actively
> engaged in security work the restrictions often appear arbitrary,
> capricious, and unmotivated.  I have been told on good authority
> that they really aren’t, but it’s hard to believe that, given that the
> browser vendors don’t enforce similar constraints against
> Javascript.)
>
> What I end up doing is configuring Apache on my server to work
> as a proxy server, and specifying in the .htaccess configuration
> file for a particular directory that if the user requests resource
> XYZ/W/VU.xml from that directory, the server should fetch
> http://ww.otherserver.example.com/W/XYZ/VU.xml (or whatever)
> and send it to the client.
>
> In shared hosting environments, the service provider sometimes
> won’t allow using Apache as a proxy; in that case, I write a simple
> bash or PHP script to do essentially the same thing (taking care to
> serve a clearly identified set of URIs from a clearly identified
> originating host, to try to minimize whatever security exposure there
> is in such a proxy service).
>
> I hope this helps.
>
> 
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> cms...@blackmesatech.com
> http://www.blackmesatech.com
> 
>
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Xsltforms-support mailing list
Xsltforms-support@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xsltforms-support