I need to send the response of a api call to another server, is there a secure way of doing this? I need to make sure that the client server doesn't tamper with the data too.
The goal is to allow the user (with there own api key) to make a request to a 3rd party api, and securely give the response to me to verify information. This needs to be done, given that the the 3rd party api doesn't have oauth support.
As you've not had a response for a month, I'll have a pop at a broad answer.
The 3rd party API server would need to store a return URL against the client's API key. When they receive a request using the client's API key they will match the key with the URL in their database and send the response to that URL instead of back to the client.
This will require cooperation with the 3rd party API provider, and implementation specifics would depend on them.
An aside, oAuth wouldn't necessarily help you here as the token generation system (that I rather assume you are referring to) is only relevant for the authentication part of any API interaction, and you didn't mention specific uses.
Related
I recently learned about webhooks and am trying to implement one for a full-stack app that I'm building. However, I haven't been able to find information on how to create my own webhook. This is how my app is expected to work:
My client side is a website built with React, and when it loads, it will make a GET request to my server (built with Node and Express). The response will provide data that will be displayed on the website. The user will click a button on the website, which will send a (POST? GET?) request to my server, which will make its own POST request to send some of the data to an external API. When that external API data completes work on the data, it will send a POST request to my webhook URL (which I assume is part of my server), and the data from the external API needs to be sent to the client, which will display it alongside the original data. Additionally, when work on the first batch of data is completed, my server sends another POST request (with some more of the original data) to the external API, which will then make a POST request to my webhook/server with new data that then gets passed to the client again, and this repeats until all the original data from my server has been passed to and processed by the external API, and the all the processed data gets sent to my server and then to the client.
From my understanding, the webhook will allow my client to make a single request to my server, and then, my server can make multiple response to my client: one response for each POST request received from the external API. However, I have not been able to find information on how to create a webhook. Everything that I have found has been about how to use webhooks with pre-existing apps/websites like Dischord or GitHub or Stripe. Or using 3rd-party services to use their webhooks to connect pre-existing app/websites.
How do I go about making a webhook for my little project that will update my website every time that my server receives a POST request from the external API? Or am I misunderstanding how a webhook works? Can they only be created by 3rd-party services and/or only used on pre-existing apps?
For a simple use case, it just means another endpoint on your server that will receive a request from the external API when it's done with the task. It's a common way REST APIs work to let you know they are done with something, or communicate anything back to you in general. You have one endpoint that will receive a request from the React client, and send information off to the external API (as you said), and another endpoint (this "webhook") that will receive requests from the external API. That's it.
You described the client-server communications for this problem just fine with the exception that the server cannot send requests to the client over HTTP. If the client needs anything from the server, it needs to send a request and ask for it. A common way to do for this would be to store the information on the server once the external API hits your "webhook", and the client can ask the server if the data is back every X seconds (long-polling).
Example (payment flow):
Client -> Server: Heres my credit card number
Server -> Client: Thanks! Let me process that.
Server -> External API: Please process this credit card for the amount of $X and ping me at this webhook when you're done.
External API -> Server: OK, will let you know when I'm done.
Client -> Server: You done yet?
Server -> Client: Nope!
External API -> Server (to webhook): Hey, I'm done, here's the receipt.
Server -> External API: Thanks!
Client -> Server: You done yet?
Server -> Client: Yes! Here's your receipt.
More advanced ways to solve the problem would be using a long-lived bidirectional communication protocol such as websockets. And as others have mentioned, all of the endpoints don't have to be on the same server. You can have one server for each endpoint, and you can have turn them on only when they get a request and then go back to sleep (that's a Lambda). Pros and cons to this approach. That's more advanced stuff and if you're just learning I wouldn't really worry about it now.
AFAIK, webhooks are just normal web APIs. Properties that make an API a webhook:
The client sending requests to your server, in this case, is another server
This client will send you a request when there's a triggered event
In your case, your server POSTing data to the external API. What makes webhook different is that the external API's server doesn't have to respond right away, instead, it sends back you, for example, an HTTP 200 OK to acknowledge that it received the request and has started to process the data. When the external API's server finishes processing the data (which is an event), it will call your server's endpoint to inform you about the process along with the processed data (if succeeded).
Your server, correspondingly, will then have to inform your client (the user) about the processed data. I would suggest implementing some kinds of persistent connection (WebSocket or SSE), or simply just make the client poll request every some second.
"(which I assume is part of my server)"-- The webhook is part of the third party API that points back to either your server or maybe some serverless function/lambda(that you set up) that in turn can parse and perform computations on the data and then send it back to your server.
It really depends on the use case and architecture of your API. If you don't want your main API server to get overloaded, if say you need to perform heavy I/O, CPU/GPU processing, you could create Serverless Lambda Functions to handle this data processing and be the endpoint you supply to the third party's webhook post endpoint.
If you're not concerned with it, you could just create another endpoint in your server to handle this webhook.
Just keep in mind, when you're trying to scale up, you want your systems to be as distributed as possible-- within reason-- so your API can handle more requests and not be overloaded with a bunch of processes.
I already Googled that, but I didn't found any answer that satisfy me, maybe because it's impossible.
I want to know if I can authenticate a website directly from JavaScript to a Symfony API rest. My goal is to create a script in JavaScript, which make ajax requests to the API (the API accepts cross origin requests) and get some data in the response, but the website(s) needs to authenticate with the API to get this data.
I can certainly use JSON web tokens or OAuth to make the website authenticate as a user, but in this case I need to have some script on the server side of the website and call it from ajax to get the website authenticate and return the token in the response. I don't want to store anything on the website, only put my script tag in the html, to facilitate the installation of the service(it's a widget) for webmasters.
I also know that I can do that with referrer authentication, but I will avoid that, everyone can change referrer in the request headers. I can also put an apikey in the link of the script <script src="mydomain.com/myjs.js?apikey=MY_API_KEY"> but everyone can access the apikey and use it from everywhere.
Is there a way to do that safely?
After some research I think the only solution is what I already done, apikey-referrer authentication:
How to keep API keys secret when using client side Javascript?
How does Google Maps secure their API Key? How to make something similar?
Please see below:
My app receives request from the user.
My app makes an API call to the 3rd party application using request module.
In order 3rd party API to work properly it needs to receive USERS IP and header information. (It's an ad server). But when I send a request through my app -as expected- 3rd party receives my app server's IP and headers.
The question is:
How can I make my application's request to the 3rd party API to "seem like" the user? How can I "clone" the request of user's to 3rd party?
Thanks
For copying the headers, it sounds more like you need a proxy.
For the IP: if im not completely off, i would say this is impossible as you have no influence on the IP Address that your Computer/Server gives to the packages send over the wire.
To put it in OSI-Words: Your NodeJS Instance is on the Application Layer, while the IP Address is handled within the transport layer.
All I can think of you could do is to forward a link to your user to the actually 3rd Party API and let him call it.
I'm trying to create a web application which will have a component to retrieve 3rd party data from Twitter. Assuming that I've registered my application with Twitter and have a token:
Is the preferred location to store my token on my server side code (I'm using Node / Express for my backend)? The alternative would be to store it on my client side code but that seems really dangerous since everyone would be able to inspect my code.
Assuming that I do store my token on the server side, does this mean that if I want to make AJAX calls to the 3rd party API (i.e. Twitter), the flow of the request would be from client to server, and then server to 3rd party web service?
If the above case is accurate, then would my server side code have to include some asynchronous callback / promise logic such that once the data is ready from the 3rd party web service, the server will execute my callback to send the data back to the client side?
This answer makes the assumption that you are using Twitter's "application-only authentication" to make API requests on behalf of the application itself (https://dev.twitter.com/oauth/application-only).
Your server side code is the preferred location to store any API keys you do not wish to make public. The developer guidance from Twitter states "These values should be considered as sensitive as passwords and must not be shared or distributed to untrusted parties."
Yes, using an authentication model like Twitter's "application-only authentication" would require that all third party API requests be proxied through your server side code in order to protect the API token. The same is true for any third party API that requires a simple, static API key to be passed with each request.
Although it may not technically be necessary, use of asynchronous operations on the server side when making third party API requests is preferred. This will give you a more robust architecture for dealing with the instability of internet requests as one benefit.
If you intend to read or post Twitter data on behalf of visitors to your website, be sure to read more about other methods of obtaining access tokens for use with Twitter: https://dev.twitter.com/oauth/overview. For example the "3-legged authorization" method is better suited to this scenario as it provides a secure way for the end-user to supply their Twitter credentials and authorize use of their data by the requesting application.
I'm calling a webservice using the REST methodology using JSON/JS/jquery and am wondering if there is a way to call the webservice without exposing my API keys in the source code. Anyone know of a way to hide the API keys from the public and still make the call?
I'm worried that if someone goes through my source, they will be able to use my API key.
You could delegate the calls to your own server, so instead of:
Browser sends HTTP request to external REST API, with API key
External REST API sends response to browser
you have
Browser sends HTTP request to your server
Your server sends HTTP request to external REST API, with API key
External REST API sends response to your server
Your sever sends response to browser
I'm not sure that someone else "stealing" your API key is a huge problem, though, since API keys (Google, for example) are frequently associated with specific domains.
There's no way to send the API keys to the client, and have them be usable, and not have them be exposed. What you more likely want is to have a translation layer, where you allow external (non-validated) clients to make requests against an exposed endpoint, then you use some sort of logic to validate the request, then pass through the request.
API keys are typically for your use as a partner, not for distribution; this is the way to avoid distributing them.