Actually, DNS servers, particularly for reverse DNS lookups, are out of the
control of a huge number of authors on the web. Shared hosting accounts for
instance don't have a unique reverse IP look up. There are also plenty of
The reverse DNS spec specifically allows one IP address to have
On Mon, 23 Jun 2008 09:34:27 +0200, Frode Børli [EMAIL PROTECTED] wrote:
[...]
I'd suggest looking into the work the W3C has been doing on this for the
past two years:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
http://dev.w3.org/2006/waf/access-control/
--
Anne van Kesteren
Hi! Thank you for pointing to that document. I quickly scanned trough
it but I have a small problem with the specification: does it require
web servers to check the Origin header? What happens with older web
applications that do not check this header?
Frode
2008/6/23 Anne van Kesteren [EMAIL
On Mon, 23 Jun 2008 14:18:22 +0200, Frode Børli [EMAIL PROTECTED] wrote:
Hi! Thank you for pointing to that document. I quickly scanned trough
it but I have a small problem with the specification: does it require
web servers to check the Origin header? What happens with older web
applications
I have a proposal for a cross domain security framework that i think
should be implemented in browsers, java applets, flash applets and
more.
The problem:
If browsers could connect freely to whichever IP-address they want,
then a simple ad on a highly popular website can be used to trigger
The tools available:
The browser. The server. DNS servers.
Actually, DNS servers, particularly for reverse DNS lookups, are out of the
control of a huge number of authors on the web. Shared hosting accounts for
instance don't have a unique reverse IP look up. There are also plenty of
people who
(Frode, this is one of those lists where you have to hit reply all instead
of just reply to send your response to the list. I'm assuming you meant for
that, apologies if you'd meant it to be a private reply.)
On 20/06/2008 15:01, Frode Børli [EMAIL PROTECTED] wrote:
Actually, DNS servers,
1. Browser downloads a script from server A.
2. Script tries to connect to server B.
3. Browser looks up server B's IP-address.
4. Browser performs a reverse lookup of server B's IP-address and gets
a host name for the server.
5. Browser looks up a special TXT record in the DNS record for Server
1. Browser downloads a script from server A.
2. Script tries to connect to server B.
3. Browser looks up server B's IP-address.
4. Browser performs a reverse lookup of server B's IP-address and gets
a host name for the server.
5. Browser looks up a special TXT record in the DNS record for
On Fri, Jun 20, 2008 at 7:31 PM, Frode Børli [EMAIL PROTECTED] wrote:
If the socket is created like this: var socket = new
WebSocket(http://www.example.com/chatserver.xsocket;);
Then the .xsocket file is an XML file specifying exactly how the
WebSocket should connect to the server and perhaps
Web applications could still easily ported from one system to the
other, because the file would be processed transparently.
The only problem I see is getting the allowed domains right, the
xsocket file can point to. On the one hand, you may want a dedicated
machine for the persistent
11 matches
Mail list logo
