[JDEV] RE: File Transfer [was buddy icons]

[Robert Temple]

> -----Original Message-----
> From: Thomas Parslow (PatRat) [mailto:patrat at rat-software.com]
> Subject: Re[2]: [JDEV] Buddy icons & File Transfer
> 
>>
>> Instead, I think I'll just build another mini-web server or maybe 
>> an NSAPI or ISAPI DLL that both senders and recipients will connect 
>> to simultaneously to send a file.  When the sender decides to send
>> a file, the client will first connect to this server and do a post 
>> that tells this web server that it wants to send a file.  This web 
>> server will respond with a unique URL that the client will use to 
>> give to the recipient.   The client will remain connected to this 
>> web server, and then send a iq:oob to the recipient, with the 
>> corresponding  URL.  The recipient client will then connect to that 
>> web server and do a GET on that URI.  Once the recipient is 
>> connected, then he will send an iq:oob result back to the sending 
>> client.  When the sending client gets this, it will start pushing 
>> the file to the web server.  Once its done, it will close up the 
>> connection.   The web server will pipe the data it gets from the 
>> post back to the recipient's connection.  The recipient will GET 
>> the file and everyone is happy.
> 
> But that would be incompatible with the current systems...

How would it be incompatible?  

> Wouldn't it be easier to send the senders ip as part of an url then as
> soon as the other client connects to this and requests the file (an
> http get) the sender stops listening on that port. So while it would
> be possible for a third party to get the file by eavesdropping on the
> conversation and grabbing it before the other client does it would be
> quite unlikely :)

In P2P file transfers, the sender's IP is part of the URL, for example: 
http://232.132.0.3/foo/file.exe. But we where talking about file 
transfers when a firewall was in the way.  So I wouldn't need to send
the sender's IP in that case, but the IP of the web server instead.

It certainly would be easy for a 3rd party to snoop on a conversation 
and grab the file in place of the intended recipient.  I believe
that would be a major security hole for our users and some hacker
would take advantage of it eventually.

> That way would remain compatible with the other way being used in
> clients like JabberIM and WinJab, the receiver does not need to know
> whether he/she is downloading directly from the sender or via a third
> party.

When you say compatible, I'm guessing you are talking about the
recipient having to send the "result" back before the file actually
starts flowing across the pipe?

I don't understand why this wouldn't work in WinJab.  Back a number of 
months ago I was told that this was the right way to do things.  The 
"jabber:iq:oob" section in the JPG, in the "result" method also suggests 
that this is the correct way to send and receive files.  I do know that 
there isn't much documentation on this, so I wouldn't be surprised if 
there are some incompatibilities.  Clearly this needs to be documented 
better.

-Robert