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 last year.
Improve this question
What of the following two use cases are defined as RPC:
1
Client side serialize the code into binary format for example a python function gets pickled and put into the body of a message.
The message is send to the server and then the server deserializes it and runs the function code. Takes the outcome and send the outcome back via network to the client.
(code is defined client side and performed server side)
2
The client send a message with only the name text format of the method the server should perform. The server has the method defined on his side and runs the method. Afterwards the results got sent over the network back to the client.
(code is defined server side and performed server side)
It seems that most people believe RPC is only defined and used as in the 2 use case. Another question: Grpc is only build and meant for the second use case isn't it?
RPC stands for "Remote Procedure Call". Both of your definitions are doing exactly this, doing remote call of some code with passing (serializing) arguments and returning result (serialized).
The only difference between both definitions is such that 1st definition sends serialized code to remote server, while 2nd uses code already located on server. But still 1st and 2nd are both kinds of RPCs, just differently implemented.
2nd definition is related to API ("Application Programming Interface"), because only 2nd definition has well-defined interface of pre-defined functions with fixed signatures. You "know" what functions are located in API and what params they need. Hence in 2nd case you just reference those remote functions by their names (or anyhow else), instead of sending code itself.
If to choose between two definitions then 2nd is more classical definition of RPC, it is closer to what usually people mean when speaking about RPC.
2nd case also is more secure - because 1st case allows Client to execute arbitrary unchecked/unreliable code on server, which can harm it. While 2nd case allows server to strictly decide what should be run with what types of params.
2nd case is also more informative, because API usually has lots of detailed documentation regarding each function awailable and its properties. In 1st case Client has to have deep understanding of Programming, because arbitrary code is not documented so well anymore as in 2nd API case.
But if you have 2nd case it doesn't mean that you can't have 1st case same time. For example inside 2nd-case API you can just implement function ResultTuple CallAnyCode(FunctionCode, ArgumentsTuple) - this kind of function may allow you to execute arbitrary code remotely. So you have well defined rich API with many function and inside this API there is one function to run arbitrary code (maybe with some higher authenticated rights of Administrator). This is also a common practice on some Servers. In this case 2nd definition will be including 1st definition inside it.
Regarding GRPC ("Google Remote Procedure Call") - it is just one possible implementation of RPC concept provided by Google and used widely inside all Google services as well.
GRPC has well defined strict interface of all functions (API). Every function has a name and format of input Protocol Buffer, basically all parameters described in structured binary form (similar to JSON but serialized in compact binary form). Resulting Protocol Buffer is also strictly described.
So GRPC actually corresponds to your 2nd definition. Because code is located on server and has strictly defined interface. And functions are referenced just by their names, without uploading any code to server.
But this doesn't mean that GRPC can't be used for executing arbitrary code. Still you can create GRPC function Result_ProtoBuf CallAnyCode(Code_plus_Arguments_ProtoBuf) through which you can pass arbitrary serialized code to server and execute it there, if you have enough permissions. In this case GRPC makes a function-wrapper that actually implements 1st definition also.
Related
a portion of my application involves creating tests (i.e., picking x-number of questions from a filtered set of questions). The user is able to determine how big they want the test but to do so I need to calculate on the server how many questions are available. The function which creates the test is sent through this post:
app.post('/user/create_test', users.create_test);
As the user changes filters, I would like to determine the number of questions available... All I can think of is to use AJAX post to send the filter information but it will be passed to the same function as creating a test would... is there any way to post to the same URL but determine which function you execute?
Consider creating another function. - The best way to do Restful API's.
Consider renaming to app.post('/user/test').
The second function could be app.post('/user/test/filters').
Or make a single POST request and make sure your function does both creating and filtering.
In general, the design of the app lacks maturity. Rethink the client-server communications.
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
I would like to have a fire hose like channel, where it would be possible to write data that will be retrievable by currently connected clients. I would like an API that looks somehow like this :
-- I chose IO to illustrate, but any suitable monad such as STM would be fine
newFirehose :: SomeConfiguration -> IO (Firehose a)
ghReader :: Firehose a -> IO (FirehoseReader a)
closeReader :: FirehoseReader -> IO ()
broadcast :: Firehose a -> a -> IO ()
-- returns nothing for closed readers
receive :: FirehoseReader a -> IO (Maybe a)
The requirements I came up with are :
It should be possible to add and remove clients at will, which means something like dupXXX and closeXXX, but where closing doesn't terminate everything.
It is acceptable to have an interface with read-only and write-only types.
It should use a bounded amount of memory.
A client that does not read from the fire hose, or that is slow, must not block the other clients.
It is acceptable to discard values.
In the absence of performance problems, all clients should receive the same data.
I don't think there is an already written Chan-like module for that, and it doesn't seem trivial to write. Here are my questions :
Is there already something out there that would be usable ?
Am I missing a crucial requirement ?
Can someone share pointers or ideas on how to write such a structure ?
Edit : this is actually a very useful construct. Here is what I would use it for : it happens that I have several message busses in my production system. I would like to be able to dynamically connect remote clients to this bus in order to inspect some messages, while they are in transit, in real time. This is useful for debugging and reporting.
You probably will need some sort of IORefs to hold data and lists of clients. One possible solution would be to keep a list of client handlers ([a->IO()] functions inserted by clients to "subscribe"). This has the advantage of not needing to store the data itself anywhere once the broadcast is finished, thus adhering to the 'bounded memory' requirement. Your subscribe and broadcast functions would be pretty simple to write, they would just add a function to the list, and iterate through the list calling each function. The downside is that once a broadcast is finished, the data would be gone....
Another possibility would be to use IORefs to store the actual data. In this approach, you would keep a list of [a]'s and add to the list whenever something is broadcasted. Data could be sent using push (in which case you will need a separate list of [IO()] functions corresponding to the clients anyway), or pull, in which case you will need to tag each a with a sequence number or timestamp (which clients would use to determine what is new). I would avoid the pull case whenever possible (it usually involves polling, which is evil).
Honestly, if you were a client coming to me with this spec, I would push you a bit harder to determine if the spec is really what you want.... Without knowing more about the problem, I can't say for sure, but it almost sounds like you want these clients to be remote, in which case a tcp/ip server/client model might be warranted. If this is the case, ignore everything I said above, and you will probably want to add a database, and need to settle on a communication protocol.
Or perhaps you need something in the middle- Clients running in another process, but on the same computer. For this case, linked libraries or Microsoft COM objects (wrapped around a database, or even just a few files) might fit the bill.
I suspect all the downvoting is because the specs aren't that clear, as any of these very different answers that I have given you could possibly answer the requirements. (I wan't one of the downvoters).
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
I come from mysql background, and I am aware of typical security concerns when using mysql.
Now, I am using mongodb (java driver).
What are the security concerns, and what are possible ways of avoiding security problems?
Specifically these areas:
1) Do I need to do anything for each get/post?
2) I store cookies from my application on client side and read those later (currently the only information I store is user's location, no sensitive information), Anything I should be careful about?
3) I have text boxes, text areas in my forms which users submit. Do I need to check for anything before saving data in mongo?
Can anybody provide any instances of security problems with existing applications in production?
It is in fact possible to perform injections with Mongo. My experience with it is in Ruby, but consider the following:
Request: /foo?id=1234
id = query_param["id"]
collection.find({_id: id})
# collection.find({_id: 1234})
Seems innocuous enough, right? Depending on your HTTP library, though, you may end up parsing certain query strings as data structures:
Request: /foo?id[$gt]=0
# query_param["id"] => {"$gt": 0}
collection.find({_id: id})
# collection.find({_id: {"$gt": 0}})
This is likely less of a danger in strongly typed languages, but it's still a concern to watch out for.
The typical rememdy here is to ensure that you always cast your inbound parameter data to the type you expect it to be, and fail hard when you mismatch types. This applies to cookie data, as well as any other data from untrusted sources; aggressive casting will prevent a clever user from modifying your query by passing in operator hashes in stead of a value.
The MongoDB documentation similarly says:
Field names in MongoDB’s query language have semantic meaning. The dollar sign (i.e $) is a reserved character used to represent operators (i.e. $inc.) Thus, you should ensure that your application’s users cannot inject operators into their inputs.
You might also get some value out of this answer.
Regarding programming:
When you come from a mysql background, you are surely thinking about SQL Injections and wonder if there is something like that for MongoDB.
When you make the same mistake of generating commands as strings and then sending them to the database by using db.command(String), you will have the same security problems. But no MongoDB tutorial I have ever read even mentions this method.
When you follow the usually taught practice of building DBObjects and passing them to the appropriate methods like collection.find and collection.update, it's the same as using parameterized queries in mysql and thus protects you from most injection attempts.
Regarding configuration:
You need, of course, make sure that the database itself is configured properly to not allow unauthorized access. Note that the out-of-the-box configuration of MongoDB is usually not safe, because it allows non-authorized access from anywhere. Either enable authentication, or make sure that your network firewalls are configured to only allow access to the mongodb port from within the network. But this is a topic for dba.stackexchange.com
I'm building a service which is fragmented across multiple modules that are required when necessary.
I need to access the "request" variable from the router in all my modules.
My current solution (which has been suggested in other threads for passing variables in general) is to pass it to each required module:
var a_module = require('./a_module')(req);
And exporting each module as functions:
module.exports = function(req) {
...
}
But it is verbose and involves having to export my modules as functions, and only having access to this variable in the scope of the exported functions. Ideally I would like to be able to access the variable across the entire required module.
Is there any other elegant way to do it that I am missing? Like declaring the req variable as a global across the entire application?
This question is going to solicit opinions not answers, so it's not a great fit for stack overflow, but here's my $0.02.
You need to step back and ask yourself if you have really written so many modules that need access to a request object. I don't think you have. What you should be writing are functions that take the specific data they need - no more, no less. All these functions almost certainly don't need the entire request. How many of them really need access to every HTTP header, for example? Think of your program as a set of operations on domain objects/data. For example, maybe there's a function that takes a user account record and promotes it from a regular user to an administrator. All that function needs is the user account. It should not be coupled to an HTTP request object.
Just write a bunch of cleanly decoupled functions that take a small number of precise parameters and do something useful with them. This is called "loose coupling". Then organize groups of related functions into a module. This is called "cohesion". Then use some "glue" code to extract the necessary parameters from the HTTP req object and pass them as arguments to these functions. These same functions should work for a command line interface or another non-HTTP interface. They will be easier to understand, test, and more long-lived if you code them that way instead of going nuts with every line of every module knowing about the current HTTP req object.
In our domain-driven application, we use a type called ServiceResponse<> to send data between layers of our application - specifically, one is returned by every method in the domain. As of right now, it encapsulates the data (if any) which was returned from the method, or any errors that it may have generated.
My question, then, is this: is it an acceptable practice to add fields to this object that may be useful in other layers of the application? For example, is it good form to add a Status or StatusCode field to it that may be interpreted later by the service layer for use as an HTTP status code (with or without some mapping)?
It sounds like a fine place to me. The idea that every method returns a "response" of some sort smells a bit like trying to decouple too much, but there are some cases where such extreme decoupling is warranted.
In any case, the ServiceResponse could easily have a status, and if it needed one, that is where I would put it.