what did you think of forcing implementers of JSON http services to be consumed by JSONRequests, to send an extra HTTP header called X-Allow-Foreign-Hosts, per what we discussed in past threads with caxhr to address similar issues. As a developer, there'd be no way you'd set this extra header without understanding the consequences of exposing the service?
On 3/18/06, Douglas Crockford <[EMAIL PROTECTED]> wrote: > > The mimetype you're defining, because it is new, pretty-much ensures > > no existing service behind an intranet could be affected. > > > I could still envision one day developers setting-up JSON syndication > > services behind an intranet, not quite grokking the fact that their > > data is now accessible from outside of their intranet. Silly, i know > > but ... > > It is a concern. The only solution to that that I can see is education. When > choosing a technology for a service, whether SOAP or REST or JSONRequest or > whatever, you need to understand the pros and cons. A con with JSONRequest is > that if your are incompetent in determining your authentications, then data > may > leak. For that reason, some people might choose to not use JSONRequest, and I > could support such a decision. But for people who want to use it (and that > includes me), we must be prepared to design our systems correctly. I know this > is a controversial position. > > http://www.JSON.org/JSONRequest.html > -- Chris Holland http://chrisholland.blogspot.com/