Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
I made a website which communicates with a Flask server, but it's using URL request for communication and that feels insecure and abusable. Plus, I'm sending complicated data (which contain slashes and line breaks) and large data.
So can I communicate with other ways?
This is a big question with a lot of possible solutions. Here's my crack at it below:
I would not send large data through an HTTP request. Consider using an intermediate store such as an NFS cluster or AWS S3 to store your large, complicated data. Your producer server would then do the following:
Produce the data
Upload the data to the intermediate store
Send an HTTP request to your Flask server that just contains a file path to the data on the intermediate store
On receiving the HTTP request, your Flask server would do the following:
Authenticate the request as coming from the producer store (see below)
Verify that the path is on the intermediate store and not being exploited by an attacker to load data from a different source.
Load the data from the intermediate store at the given path
Process the data
Couple of things to consider:
You need authentication between your producer and Flask server. Consider having your producer login to the Flask server at startup and gain a token. If you don't use authentication, anyone could upload a path for your Flask server to process. See: https://realpython.com/token-based-authentication-with-flask/
It's a bad idea to have HTTP request processing threads take a long time. The thread can't be responding to other requests while it is processing data. Consider using Celery workers to process large datasets instead of processing on the HTTP request thread. When your Flask server receives the HTTP request, spawn a task to process the data and immediately return to the user a status code such as HTTP 202. Your frontend can then either use polling, notifications or websockets to retrieve the results when ready.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
( I am a Beginner ).
why I should use an http request - response in Node JS when i can use the Socket.IO library?
which are the advanteges of http request - response ?
Thanks to everyone.
Web-sockets(Socket.io) and HTTP both are communication protocols. HTTP uses HTTP:// or HTTPS:// and web-socket uses ws:// or wss:// to communicate with client.
Web-sockets are designed to maintain real time connection with client. But HTTP not maintaining real time connection with client. It response to the request of the client then terminate connection with client.
So if server only provide something that doesn't change in real time or the client doesn't expect to see changes in real time then having real time connection to client is a waste of server resources(server load, traffic, etc.).
Example: Think you are searching something in google. Search results appeared in google is same as after 1 hour(or more) for the same keyword. search results are not change in real time. So think if google server use socket connection instead of HTTP connection with clients. Google servers have to maintain billions of simultaneous connections with their clients for nothing.
Also read performance comparison between web-sockets and HTTP.
Http requests are the main form of communication on the web. They are used by the client (your browser) to ask something from the server.
Socket.IO is used for 2 way communications between a client and a server. (Socket.IO uses Websockets for communication, or other fallback methods if the client does not support it)
The question here is what are you building ? A website => use simple requests. An online game => Socket.IO
If you need a two way communication, then use Socket.IO, overwise requests are just fine ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Let me see if i can explain this properly.
I am making a website where users can save some information (In this case movie information).
I am getting all the movie data from a third part api (the movie database).
So i was wondering which of these to scenarios are best performance wise?
Send empty views to my client and have a javascript fetch the movies from TMD
API on page load and render them on to the page?
Fetch the data from TMD API render it into my view and send it to the client?
I assume that the first scenario is the best one for me, since i do not have to fetch any extra data before i send my views to my user (and this way also dont use as much bandwidth).
However i feel like the second scenario makes it easier for me to manipulate the data to how i like and want it with less code as i can just render it onto the views before sending it (This way to i would have to use more bandwidth since i have to fetch some data first, and thus send more data to my client?).
As you've articulated already, there are pros and cons to each approach.
Generally you would use a server-side request if the API credentials are not safe to make public, or if you'll be serving the same content to many clients and want to act as a cache to reduce load on the third-party API. You would also do so for data that you want to process, particularly in a proprietary manner, before serving it to a client, though that's a little more obvious.
Conversely, fetching data on the client is more common when the API request will vary based on user input or client state (e.g. cookies, such as a request to a social media API from a logged in user). The downside of this is that you tend to make many more requests to third-party APIs and you may end up exhausting a rate-limited API, resulting in delays for clients.
benefits of each:
serverside rendering
1) less data has to be sent to the client (filtering)
2) API requests can be cached, especially useful if there are request limits or if heavy computations have to be done
3) Less code at the client
clientside fetching & rendering
1) dynamic content without reloading (you can just fetch some more data)
2) you don't need a real server. A static fileserver like NGINX will be enough, no programming required at the serverside.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Scenario
I am developing some sort of web based cloud storage service.
One feature is that the user can initiate transcoding of video files (so that they can be streamed on different devices).
This takes some time and I want to display a progress bar to the user.
My plan is to submit the job using ajax where it is written into a database. The ajax call returns the ID of the job in the database, and this id will be used as the channel for notifications.
So when the job has been submitted, the client subscribes to the channel "job-databaseID" on some self hosted websocket server.
Transcoding workers then periodically select pending jobs from the database table and process them. While processing they push their progress to the websocket server to the same channel where the client is listening.
The front-end application should be a website with javascript and jquery.
The back end should be programmed in PHP and MySQL and an apache or nginx webserver.
Question
Is this a proper way of using websockets?
Usually I see websockets employed in a on-to-many notification scenario. Here it is a one-to-one notification scenario.
Are there maby better alterantives for this kind one way information flow?
Also I often see channels for Websocket scenarios to be more or less long-lived. Here it is very short-lived. Would it maby make more sense to make one channel per user?
What would be a good websocket server for that kind of use? Ideally the channels would be auto-removed once no client is connected to it any more and auto-created the same way, so I don't need to take care of that.
Did you take a look at Server Sent Events as you are initiating your request via ajax so you aren't performing bidirectional communication; you only want server to push you updates when it has ones
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
A while ago I built a small app using python which allowed users to create small chat rooms. I implemented the server as nothing more than a rest API. The client makes requests and the server gives the appropriate response. The response is recieved by a JavaScript client which keeps on making subsequent requests to the server for updated data. Currently the client sends around 1 request every 3 seconds. I would like my app to be real-time(updates appearing as soon as changes are made), for that to happen I would have to narrow the request interval further to around 0.7 seconds. The problem with this approach is that it is not entirely scalable. Is there any way the server can send data to the client when updates occur?
Instead of having the clients pull the server for data, you can have the server push data to the client. The most common protocol to do so (and it is quite close to the standard HTTP protocol) is called WebSockets. WebSockets are an evolving standard, not all browsers support them equally.
Also, in case you use a reverse proxy server at the edge of your network, not all reverse proxy servers support WebSockets, which may also prevent you from using WebSockets.
See: http://en.wikipedia.org/wiki/WebSocket
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Scenario:
I have a webserver running php, I want to be able to be able to securely send a request to a separate server running nodejs and get a response back.
The node server will never need to send anything to the webserver by itself, e.g notifications/updates. So I don't think I need the 2 way communications that websockets would provide.
PHP sends a request to node, node processes the request, sends back data (most likely in JSON), php continues with it's script using the returned data.
Problem
I own the server running node, but the webserver is out in the wild. I need a way of making sure that any requests that come in to the node server are actually from the webserver not someone/something else, and I need the request and response data to be encrypted.
I have gathered I don't want to rely on something simple like checking ip addresses, I know that the webserver and the node sever will have to both have some shared secret information/algorithms to encode data. I could have a go at implementing this myself, but I know this problem is already solved with some encryption protocol / libraries.
I'm familiar with the concepts of encryption and keys, but I have never had to implement them.
Question
What is the best way to go about this?
What kind of encryption should/can I use, that is both supported by php and nodeJs?
What would be the potential security threats, if any?
I would suggest interact between two web servers using REST APIs.
REST APIs are used in these types of implementations.
If you can build proper authentication strategy, then the communication should be secure. If you enable SSL on Node, the communication will be encrypted. You can also limit by IP addresses, hostnames, and user agent strings.
Token based authentication with SSL should be good enough security. Utilize a strategy that implements nonce, and always have the tokens expire.
Implement CSRF strategy to prevent MITM attacks.
Build a token-based strategy that relies on common encryption methods, such as:
OAuth2
WSSE on Symfony2
CSRF on Express