Show HN: Include this JS library to enable cross-origin requests

by odedgolan • 13 years ago

20 30 13 years ago

silasb• 13 years ago

I would let the users know that requests get routed through a server you control.

odedgolan11• 13 years ago

It only goes through our servers if it's cross-origin. Normal http same-origin requests are left intact (and you can see it in the code). It's stated on the README but perhaps it should be more apparent.

Joe8Bit2• 13 years ago

Routing all your x-domain requests through an unknown third part via vanilla HTTP? What could possibly go wrong?

odedgolan11• 13 years ago

It's just your cross-origin traffic, which is not possible without this library, everything else will behave exactly the same.

Joe8Bit2• 13 years ago

And whoever is running this proxy will _promise_ not to log any sensitive information (API keys not the least) or otherwise use/modify the response for their own ends?

Not to mention that the API endpoint is HTTP only, meaning everything is broadcast in the clear.

Also, cross origin requests are perfectly possible without this library, it's precisely why we use JSONP and CORS.

When it comes to security, this library is a collection of anti-patterns. As well as the JS anti-pattern of not overwriting native objects, such as XMLHttpRequest in this context.

buzzedword3• 13 years ago

How is this remotely trending? Yes, HN, let's vote a MITM attack to the frontpage. This is a terrible idea.

odedgolan11• 13 years ago

Yes it allows you to do back stuff. But it also allows great things as mashups, retrieving external content easily etc.

buzzedword3• 13 years ago

Tell you what. Since I'm not a big fan of the lynchmob, here's the only positive critique I'll give you: proxying isn't an altogether terrible idea. It's not my first go to, but it does have it's place. HOWEVER. Allowing a third party to manage it, is. If you genuinely want to create some buzz and interest, source the serverside of this, and write some docs up how to deploy it to AWS, Heroku, etc. Bundle the JS with that. That'll be infinitely more useful than this service.

You're asking that I trust you will not modify the response in any way shape or form. The very nature of software dev mandates that I do not trust data that is not my own; and even then, verify it. You're asking quite a lot here. This is by all points and purposes, a man-in-the-middle attack vector.

Couto3• 13 years ago

Seems a cool idea to use with mockups and prototypes, but an awful idea to use in a serious product.

odedgolan11• 13 years ago

Why? remember your product will function exactly the same. It just makes more thing possible.

gpvos• 13 years ago

No, it will not function exactly the same, because it sends stuff through your server. That is a very important difference.

Leaving my front door open when I'm on holiday also makes more things possible. That does not mean I will like those things.

Couto3• 13 years ago

I don't doubt that your service works with the best intentions, but why should I open a security hole in my application, when I can easily avoid it by writing my own proxy and keep it private?

What happens to my application, if your service goes through a DDoS? What happens to my application, if you suddenly decide to close your service?

I'm pretty sure you can use these arguments about other services, but this service exactly, is not worth the risk.

Couto3• 13 years ago

Don't take me wrong… I would use your service in any proof-of-concept/mockup/prototype… It really helps a lot in those use cases, since is one less thing for me to worry about.

I just don't trust it enough to use in production.

Scriptor• 13 years ago

This is just a proxy. If developers wanted to go this route they would set up the proxy on their own server instead of routing it through a 3rd party.

odedgolan11• 13 years ago

It's possible, we just make it easier. This library also make it seamless (you can still use jQuery.ajax). They can use this library and just change the proxy url.

untog• 13 years ago

Overwhelmingly terrible idea. Routing your web site traffic through an entirely unknown third party server. Overwrite the global XMLHttpRequest object.

Please tell me this is a joke to show off terrible security practise?

odedgolan11• 13 years ago

Regrading overwriting XMLHttpRequest, if it works - it works, and if it breaks it can be improved, this is why it is open source. It does not reroute your site traffic just your cross-origin site traffic, which practically does not exist without this library. Yes it can be used to do bad thing but also opens up the opportunity for mashups, external content integration, api calls and more.

drderidder2• 13 years ago

Please don't use this. JSONP and CORS are the accepted methods for cross origin requests.

odedgolan11• 13 years ago

You can only use JSOP and CROS with sites you have control over or are designed to behave and support external requests. It makes it very very limited!

mkohlmyr• 13 years ago

"You can only use JSOP and CROS with sites you have control over or are designed to behave and support external requests."

That's kind of the point.

Rami114• 13 years ago

If you need to ask why it is bad to route traffic through an untrusted third party over HTTP, for the love of god stop building web applications. This is not the right tool for the problem it's trying to solve.

odedgolan11• 13 years ago

"untrusted" is the issue here, and trust is built over time. In the meanwhile you can use the library and implement the server side.

jscheel• 13 years ago

I'll probably never use this library for anything, but I've submitted a pull request that takes out their 3rd party proxy and merely suggests it in the error that is thrown if you don't define your own. https://github.com/TOMODOcom/TOMODOkorz/pull/1

captn3m0• 13 years ago

If you trust Yahoo!, you can try proxying requests via Yahoo Pipes for Cross-Origin support. Not that I recommend it, though.

[1] https://gist.github.com/psychemedia/316660

Show HN: Include this JS library to enable cross-origin requests

Related Stories