The only other danger of code injection with this solution (that I can think
of!) lies in taking advantage of the requirement of all arguments needing to
conform to NSCoder. Malicious data from a third party may disguise itself as
an NSData in such a way as to cause some buffer overflow or something, and
then execute arbitrary code. I don't have any clue how likely this is or how
difficult it would be to do, or to prevent/protect against.
-Steven
On Wed, Jan 20, 2010 at 3:15 PM, nicolas berloquin <cepak...@gmail.com>wrote:
> This is a genuine question/remark that pops up. No check is done on what
> selector or object is returned or is it ?
> If this is done on a public service (web server or other), couldn't code
> injection be too easilly done that way ? (easy hacking, wilfull crash etc) ?
>
>
> Le 20 janv. 2010 à 19:47, Steven Degutis <steven.degu...@gmail.com> a
> écrit :
>
> Oops, correction: the downside is that all arguments and return values
>> need
>> to conform to NSCoder protocol. So, it's even more strict than I described
>> earlier. But it's still cool :)
>>
>> -Steven
>>
>> On Wed, Jan 20, 2010 at 12:40 PM, Steven Degutis
>> <steven.degu...@gmail.com>wrote:
>>
>> Recently I had the same issue you were having, sort of. And I came up
>>> with
>>> a solution I really liked.
>>>
>>> When I was playing with Distributed Objects, I fell in love with the
>>> abstract simplicity. However, it blocks and that's bad. It's even worse
>>> when
>>> the server stops responding, because you could potentially have a 60
>>> second
>>> timeout before the single method will return. It's a potential disaster.
>>>
>>> So, I wrote an elegant compromise. Code is still written inline, no
>>> callbacks or delegate messages needed. But, it requires Blocks (and thus
>>> 10.6) to work.
>>>
>>> Essentially, I wrote some code on top of AsyncSocket (which is a
>>> brilliant
>>> framework by the way) that allows me to wrap up ObjC messages as NSData,
>>> send it across the server, and unpack it on the other side. The other
>>> side
>>> then responds to the ObjC message as if it was called right inside the
>>> application. (All this is thanks to NSInvocation's ability to introspect
>>> an
>>> ObjC message, by the way).
>>>
>>> The problem came when I had to return values. As long as the return value
>>> was void, this worked like a charm. But once I wanted to return an array
>>> of
>>> strings or a number, I had to define a method in the sender's protocol to
>>> receive such information. This is akin to your "thousands of delegate
>>> messages" you would have to implement, as you stated.
>>>
>>> So, using Blocks and NSInvocation and AsyncSocket, I ended up writing
>>> code
>>> that allows me to write code like this:
>>>
>>>
>>> // protocol.h
>>>
>>> @protocol ServerProtocol
>>>
>>> - (NSNumber*) calculatePiAndKillTime:(NSNumber*)shouldKillTime;
>>>
>>> @end
>>>
>>>
>>> // client.m
>>>
>>> - (void) someMethod {
>>> id <ServerProtocol> server;
>>> NSNumber *sure = [NSNumber numberWithBool:YES];
>>> [[server calculatePiAndKillTime: sure]
>>> returnedValue:^(id value) {
>>> // this will be called later on at some point
>>> NSLog(@"pi = %@", value);
>>> }]
>>> }
>>>
>>>
>>> // server.m
>>>
>>> - (NSNumber*) calculatePiAndKillTime:(NSNumber*)shouldKillTime {
>>> if ([shouldKillTime boolValue])
>>> // synchronously watch some film
>>> [self goWatchTheNewStarTrekFilmFrom2009];
>>>
>>> return [NSNumber numberWithFloat: 3.14];
>>> }
>>>
>>>
>>>
>>> All methods sent to a destination's proxy are sent asynchronously. And,
>>> as
>>> you can see, the return value of the method -calculatePiAndKillTime: is
>>> not
>>> actually an NSNumber, but rather a proxy that waits for a response from
>>> the
>>> destination. When the destination responds to the source with a return
>>> value, the method -returnedValue: is called with the value.
>>>
>>> But that's only half of the coolness.
>>>
>>> The other half is that methods can simply return the value they want
>>> right
>>> inside the method, no hacks necessary or anything by the programmer. In
>>> this
>>> case, we just use this line of code: return [NSNumber numberWithFloat:
>>> 3.14]; and then the NSNumber object is packaged up and sent back to the
>>> source through the proxy, all automagically.
>>>
>>> The main downfall of this is that every argument and return value must be
>>> an ObjC type, no scalars or structs or anything else will work with this
>>> system. (Mike Ash explains pretty well on this blog why trying to support
>>> those things can lead to some unfixable trickiness, which I just wanted
>>> to
>>> avoid altogether.)
>>>
>>> If you can't support 10.6, then, this won't work. But hopefully you can
>>> soon ;)
>>>
>>> Good luck.
>>>
>>> -Steven
>>>
>>>
>>>
>>> On Wed, Jan 20, 2010 at 11:39 AM, Carter R. Harrison <
>>> carterharri...@mac.com> wrote:
>>>
>>> I need some folks experienced with cocoa and socket programming to weigh
>>>> in for me on some design problems I've been having. I'm designing an
>>>> application that acts as a client in a client-server model. The client
>>>> communicates with the server over the network by issuing a request and
>>>> then
>>>> receiving a response. Requests can only be issued one at a time,
>>>> meaning
>>>> that a request cannot be sent until a response from any outstanding
>>>> request
>>>> is first received. My application works in such a way that the it could
>>>> request a handle to an object on the server and then use that handle in
>>>> subsequent requests to retrieve additional information about the object.
>>>> I
>>>> see two ways of modeling the application - I've tried both and I'm not
>>>> particularly happy with either.
>>>>
>>>> The first is to send a request, and then have the socket block until a
>>>> response is received. This benefit to this model is that it is so much
>>>> easier to write the higher level application code. The issue with this
>>>> model is that over a slow network connection it can take a considerable
>>>> amount of time for the response to come back from the server and while
>>>> that
>>>> is happening my CPU usage is through the roof b/c the thread is
>>>> blocking.
>>>>
>>>> The second way is to send a request and then let the NSInputStream call
>>>> a
>>>> delegate method when the response data is available. The response data
>>>> is
>>>> then pushed up through my protocol stack and finally up to the higher
>>>> level
>>>> application code. The benefit to this method is that CPU usage is
>>>> minimal
>>>> due to the fact that I'm no longer blocking, but the downside is that
>>>> the
>>>> higher level application code is so much more difficult to write because
>>>> I
>>>> have to write about a thousand methods to act as a callback for each
>>>> request
>>>> in a series of requests.
>>>>
>>>> I've provided an example of how I see each working below. My first
>>>> question is, is there other ways to design an application around this
>>>> client-server model that I'm not thinking about? My 2nd question is, if
>>>> there aren't other ways, how can I adapt either method that I have
>>>> outlined
>>>> to make it work a little bit better?
>>>>
>>>> As an example let's say the server knows about the following objects:
>>>>
>>>> 1. VendingMachine
>>>> - An object that represents a vending machine.
>>>> - A vending machine contains Soft Drink objects.
>>>> 2. SoftDrink
>>>> - Has the following properties: drink name, price, number of
>>>> calories.
>>>>
>>>> If I use the blocking model, I could write my code like this. The code
>>>> is
>>>> simple to write but I'm forced to wait for the server to respond with
>>>> information on pretty much every line of code. If the vending machine
>>>> had
>>>> enough soft drinks it could take a long time to iterate over each one
>>>> and
>>>> have the server respond with the drink's name of each drink.
>>>>
>>>> -(void)printDrinkNames
>>>> {
>>>> VendingMachine *machine = [server fetchVendingMachine];
>>>> NSArray *softDrinks = [machine getSoftDrinks];
>>>> for (int i = 0 ; i < softDrinks.count ; i++)
>>>> {
>>>> NSString *drinkName = [[softDrinks objectAtIndex:i] name];
>>>> NSLog(@"Found a drink named %@", drinkName);
>>>> }
>>>> }
>>>>
>>>> Likewise if I do the non-blocking approach I would have to have a method
>>>> that gets called for each step in the process (see below). This model
>>>> drives me crazy b/c the higher level application code is long, has tons
>>>> of
>>>> methods, and is just difficult to read and maintain. The example I have
>>>> provided is simple enough to get the point across, but in reality some
>>>> of
>>>> the processes I'm trying to drive are much more complex and require
>>>> numerous
>>>> callback methods to pull off.
>>>>
>>>> -(void)printDrinkNames
>>>> {
>>>> [server fetchVendingMachineWithCallBackObject:self
>>>> selector:@selector(didFetchVendingMachine:)
>>>> }
>>>>
>>>> -(void)didFetchVendingMachine:(VendingMachine *)machine
>>>> {
>>>> [machine fetchSoftDrinksWithCallBackObject:self selector:@selector
>>>> (didFetchSoftDrinks:)];
>>>> }
>>>>
>>>> -(void)didFetchSoftDrinks:(NSArray *)drinks
>>>> {
>>>> for (int i = 0 ; i < drinks.count ; i++)
>>>> {
>>>> SoftDrink *drink = [drinks objectAtIndex:i];
>>>> [drink fetchNameWithCallBackObject:self selector:@selector
>>>> (didFetchDrinkName:)]
>>>> }
>>>> }
>>>>
>>>> -(void)didFetchDrinkName:(NSString *)name
>>>> {
>>>> NSLog(@"Drink name is %@", name);
>>>> }
>>>>
>>>> _______________________________________________
>>>>
>>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>>
>>>> Please do not post admin requests or moderator comments to the list.
>>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>>>
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>>
>>>> http://lists.apple.com/mailman/options/cocoa-dev/steven.degutis%40gmail.com
>>>>
>>>> This email sent to steven.degu...@gmail.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Steven Degutis
>>> http://www.thoughtfultree.com/
>>> http://www.degutis.org/
>>>
>>>
>>
>>
>> --
>> Steven Degutis
>> http://www.thoughtfultree.com/
>> http://www.degutis.org/
>> _______________________________________________
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/cepakare%40gmail.com
>>
>> This email sent to cepak...@gmail.com
>>
>
--
Steven Degutis
http://www.thoughtfultree.com/
http://www.degutis.org/
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
