My app was hosted in xxx.com, which gets data from yyy.com. All API requests were triggered from client side.
Is there a way to intercept its request or response in node?
No, and Yes.
For the requests made by your client, you must have some control of the data sent back to the client in order to intercept it.
Assume a scenario where:
Client -----(request)----->Third Party App Server -------(response)-----> Client
In this case, as the back-end server never had a chance to come into picture, there is no way the server can change the data. Well of course, that is when the server doesn't come into picture.
Instead, if you send the request to the node server itself, which forwards the request to the Third Party App server, you obviously have control of the response receive and thus, you can manipulate both request and response or maybe just log it (whatever is your use case).
Client -----(request)----->NODE_SERVER---->Third Party App Server -------(response)-----> Node_Server ----> Client
What a few developers do to intercept the requests made from the client is that they write some client-side JavaScript code and embed it into the browser (Some sort of authentication).
While this works okay in case of normal requests, a person with malicious intents might just disable your front-end interception code and directly receive a response from the Third Party application.
Thus, if you really need to have access to the requests and response,
YOU MUST FORWARD THE REQUESTS TO AN APP SERVER YOU HAVE CONTROL TO.
P.S. It is not just about nodejs.
Related
Normally i use ajax http requests to get/post data. Now i have thoughts like why shouldn't i replace all the ajax get requests with socketIO?is there any disadvantage in following this approach?
I understand that session cookies via http headers will be sent between client and server during every http requests, during client<=>server interactions using sockets, will the session cookies in browser automatically sent to the server via socket headers(if that exists)?
In which usecases should i prefer SocketIO over Http?(if you consider this as a question that demands broad answer then you can link me to some relevant articles)
WebSockets are useful when the server needs to push some real time information to the client about some events that happened on the server. This avoids the client making multiple polling AJAX calls to verify if some event has occurred on the server.
Think of a simple chat application. If the client needs to know if the other participant in a chat session has written something in order to display it, he will need to make AJAX calls at regular intervals to verify this on the server. On the other hand WebSockets allow the server to notify the client when this even occurs, so it is much more efficient in terms of network traffic. Also the WebSockets protocol allows the server to push real time information to multiple subscribed clients at the same time: for example you could have a web browser and mobile application subscribed to a WebSocket and talking to each other directly through the server. Using AJAX those kind of scenarios would be harder to achieve and would require much more stateless HTTP calls.
I understand that session cookies will be sent between client and server during every http requests, is this case the same during client<=>server interactions using sockets
The WebSockets protocol is different from the HTTP protocol. So after the initial handshake occurs (which happens over HTTP), there are no more notion of HTTP specific things such as cookies.
There's one important thing that you should be aware when using WebSockets: it requires a persistent connection to be established between the client and the server. This could make it tricky when you need to load balance your servers. Of course the different implementations of the WebSockets protocol might offer solutions to this problem. For example Socket.IO has a Redis implementation allowing the servers to keep track of connected clients through a cluster of nodes.
I am working on a frontend express.js app and need to request to a lot of apis from client side(browser) to another server. I need to request those apis from server side and send responses to browser, due to cross domain problem. I am now writing every api as a route method in my app to receive requests and re-send recieved data as responses. Because of the number of apis is huge, and rewrite every request is prone to error and hard to maintain, I wonder whether there is an express.js way to relay all requests with their methods and parameters not changed from browser to the other server. For example, if I request to some /api/test route of my server, it should request to /test route of the other server, receive response and respond it to me.
Unfortunately there is no way to change anything of the server which implemented the apis. So I could only do this work in the express.js app.
Thanks.
In my node.js server app I'm providing a service to my js client that performs some handling of remote api's.
It might very well be possible that two different clients request the same information. Say client 1 requests information, then before client 1's request is fully handled (remote api's didn't returns their response yet) client 2 is requesting the same data. What I'd want to is to wait for client 1 data to be ready and then write it to both client 1 and 2.
This seems to me like a very common issue and I was wondering if there was any library or built-in support in connect or express that supports this issue.
You might not want to use HTTP for providing the data to the client. Reasons:
If the remote API is taking a lot of time to process you will risk the client request to timeout, or the browser to repeat the request.
You will have to share some state between requests which is not a good practice.
Have a look at websockets (socket.io would be a place to start). With them you can push data from the server to the client. In your scenario, clients will perform the request to the server, which will return 202 and when the remote API will respond, the server will push the data to the clients using websockets.
I need to implement a server that can handle simultaneous connections from both a client app and a browser that share a common database, however the clients from the browser have different functions from the clients of the app. I would like suggestions if this is the best design implementation. I decided not to have a different server for the client app or from the browser for this same reason as I can foreshadow synchronization issues when retrieving/writing information form the database. Is there a way to somehow attach a string or other information in front of the http connection to be able to tell each apart?
when the connection is made to the server what should be done?
var server = http.createServer(function(request,response)
{
//Code to tell them apart
});
Your client app is the best place to start. Do you have control over the client app? If you can modify it to send a specific header, that may work. Otherwise, another way to do so is to differentiate between User Agents... If the client app will always have a specific UA, treat all requests with that UA as a client app request, and all others as a browser request.
I'm working on an application that relies on data that the browser sends within the HTTP headers (and there's no way around this). This also happens to be my first time working with something node.js based, so it's very likely I'm completely missing something simple!
Basically what I want to be able to do is call a method on the server from the client, and in that method read the HTTP headers that the client sent.
Meteor doesn't yet provide a supported API for serving HTTP from your app. This is intentional: in the not-too-distant future, your app server is likely to not be just a single process directly serving end users, but an arbitrarily parallelizable service behind a proxy tier. So we'll need to provide a supported API for responded to HTTP requests (REST, eg) that continues to work in such a setting.
Are you sure it needs to be HTTP and that you can't just use a Meteor method?
If you really need to accept direct HTTP requests now, take a peek at how packages/accounts-oauth-helper/oauth_server.js uses __meteor_bootstrap__.app to hook into the Connect middleware framework. This will work for now, but we don't promise that Meteor will always be powered by Connect :)