frenchy at gmail.com
Sat Mar 18 17:43:18 PST 2006
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 <douglas at crockford.com> 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.
More information about the whatwg