Make the api wide-open

[sasha240100]

Hello, develop a plugin registry for my project. And i would like to know if there is a way to run npms-api with openshift. I need this because your API can't be used from localhost. Thanks in advance!

[satazor]

@sasha240100 the API can absolutely run on localhost but it needs a couchdb database and elasticsearch filled with the npms-analyzer data. Did you read the architecture document?

[sasha240100]

@satazor I mean that if i try to make an ajax request it will result with such error:

XMLHttpRequest cannot load https://api.npms.io/v2/search?q=whs+plugin. 
No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://localhost:8080' is therefore not allowed access.

[satazor]

Oh that's a CORS problem. The API is not currently wide-open, it only allows origins that match *.npms.io. We can either lift this security measure or you can implement a proxy.

//cc @atduarte what are your thoughts? Opening the API will make it vulnerable against DDoS attacks, specially on sites that have high traffic and want to harm npms.io for some reason. Still highly unlikely.

[sasha240100]

@satazor I will try proxy, but IMO it's better to open API (i personally promise not to make DDOS attacks :D) Please, ping me if you decide to open API.

P.s.: Still no success with making an api server with openshift. That's all i've done: http://plugins-whsjs.rhcloud.com/

[satazor]

@sasha240100 how did you setup the proxy?

[sasha240100]

@satazor What proxy?

---

All i can tell you now is that final problem was this:

[satazor]

@sasha240100 nvm I though you created a proxy to circumvent the CORS issue. Lets wait for @atduarte opinion before deciding on wide-opening the API.

[mikeerickson]

@satazor If you don't want to open the API (which makes good sense) how about using token based access (this is how I personally setup my APIs)

[preco21]

@satazor Hmm, maybe you guys can also consider about CloudFlare. It provides DDOS protection (not sure about for APIs) and caching features. (or even already used? 😄 )

@sasha240100 Seems he meant Reverse Proxy (such CORS anywhere like).

Open API to widely +1

[satazor]

@preco21 we already use CF. At the moment, the API does not send any cache headers upstream and no caching rules are configured in CF. We can start sending cache headers though, 1m or more.

@mikeerickson we will definitively need that once we integrate with GitHub to give a more personalised search experience, but for now it would introduce complexity for little benefit.

I think it's reasonable to wide-open the API.. I don't think anyone would put a script into a high traffic website just to harm npms.io.. If that ever happens, we can consider re-enabling the CORS or add cache headers so that CF handles most traffic for us.

[atduarte]

I also think we can open it and think about changing the cache headers (CF). An open source project like this being attacked would be unusual.

[satazor]

I've wide-open the API, @sasha240100 let me know if it's now working for you. I'll add cache headers if we get high load.

[sasha240100]

@satazor Thanks! I will try once i'm at home

[sasha240100]

Works awesome thanks!

[wtgtybhertgeghgtwtg]

When using fetch, the CORS-preflight fetch for mget seems to be returning a 404, presumably because of the OPTIONS method. Is fetch not supported?

[satazor]

@wtgtybhertgeghgtwtg can you open a new issue specific to that? Thanks

[wtgtybhertgeghgtwtg]

Sorry about that. Issue #60.