Notes below: On 9/4/05, Todd Berman <[EMAIL PROTECTED]> wrote: > On Sun, 2005-09-04 at 11:15 -0400, Kevin Toppenberg wrote: > > I am working on document imaging. And more specifically, transferring > > images (i.e. binary data) to and from a Windows client, written in > > Delphi pascal. > > > > I have become convinced that transferring the file through the RPC > > Broker is the way to go: > > > > 1. It doesn't require the server to set up any sort of file server to > > the client (i.e. ftp server, or exposed file system) > > 2. It avoids potential security problems, such as users requesting > > images/files that they should not be accessing. The server function > > can screen the client requests > > 3. It would use the already-established connection--which may be a > > client outside the server's usual network. With the new xinetd > > connection method, it can no longer be assumed that the client already > > has access to the server's local network. > > > > Having decided this, I therefore need to establish binary file > > routines on the server and with the RPCBroker. To this end, I have > > written the following code: > > > > 1. BFTG -- BINARY FILE TO GLOBAL. It works just like the kernel > > function FTG, except that it handles binary data. And FYI, M globals > > appear to hold binary data with no problems. > > 2. GTBF -- GLOBAL TO BINARY FILE. Again, just like kernel GTF > > 3. CPYBG -- a binary global resizer. The kernal OPEN function > > hard-codes in a record length of 512 bytes. This might not be the > > best size for passing through RPCBroker, so this function will copy > > the binary global to a different global using a different record(line) > > length > > > > I have then written a RPCBroker call that attempt to pass back the > > binary data. I think I am writing my function call correctly, because > > when I pass ASCII data, it comes through, but when I pass binary data, > > it doesn't come through properly to the Delphi/Windows client. I have > > yet to test exactly which part of the character set messes up > > RPCBroker. > > It has nothing to do with the character set, and everything to do with > the Delphi RPCBroker client. > > If you look at xwb/Trpcb.pas in the CPRS source, you will see on line > (in my copy) 808 the start of TRPCBroker.Call. > > This code eventually uses pchCall in the same file, starting at line > 973. The comments identify this as the lowest level possible RPC call w/ > the RPC Broker. > > It looks like using anything above pchCall will not work for sure, as it > is converted into a string or a string list, however you should be able > to get it to work using pchCall, as that just returns a PChar. >
I am away from my system that has Delphi on it, so I will have to check the code to see exactly what you mean. But I am not following you here. To my understanding, Delphi strings are stored in a different format than the usual c/c++ (null-terminated) way strings are. They start with a byte(s) that specify the length, and then are followed by bytes that can hold 0-255. Thus they can hold binary data, while traditional null-terminated strings will interpret any 0 byte as an end-of-string marker. My understanding is that PChar type strings are null-terminated. Thus I am not sure if the problem is that the RPCBroker is using Delphi strings, or null-terminated strings. But I appreciate your references to the code, and I will look at that closely. > > > > So to address this problem, I had decided to use some sort of ascii > > armouring (encoding) of the binary data to get it to successfully pass > > through--such as simple hex encoding, or even UUENCODING. > > > > Maury pointed out that I should post my overall purpose here and see > > it I am working on the wrong problem. > > > > So here are my question: > > 1. Is there some good reason that I should not be passing binary data > > through RPCBroker? > > 2. Could RPCBroker be beefed up to handle binary data? > > It already does. We use it to transfer progress notes in languages that > use a MBCS very successfully. If you are not using the *Delphi* RPCBroker client, do you think that you could or could not use your same code with the Delphi code? What is different about the RPCBroker clients between platforms? > > > 3. Any other thoughts? > > Mostly, I would question the need/desire to store this data in VistA, > and access it via the RPC Broker. > > I understand the three points you made above, however it seems to me > that using some form of https (with a password) accessible webserver > makes this far more manageable from the client end. Also far more > scalable. Tasking vista to transfer potentially large binary files down > the RPC Broker connection seems somewhat like using a sledgehammer to > tap in a push-pin. Not to mention not nearly secure enough for use. > Great that you provide some 'security' by deciding if you will give a > user a file, but you could provide the same 'security' by deciding if > you will give a use a URL. But that security goes right out the window > the minute you transfer that file over the unencrypted RPC connection. > Of course, this is also a more general issue facing the current RPC > method, so it is not specific to this issue at all. > > It would seem that using urls + https + authentication is the better way > to go to handle this, as it does also 'solve' all 3 points brought up, > but (imo) in a better, more secure, and far more scalable fashion. > > --Todd Hmm... I don't know what to think about the security issue. I had a leak from my office via a standard http server and it was absolutely horrible. I had committed to not running an http server anywhere near my patient data. I know that if Apache is set up properly, there won't be any problems. But apparently it was just a click of the mouse that accidently transferrred a file from the sensitive area into the part of the file system that Apache was serving to the internet. And I plan on never having such a thing happen again. It seems that if the data is going through RPC calls and requires CPRS it is less likely to be compromised than with an http server that some hacker from Malasia etc could attack using Internet explorer etc. I guess it would take someone listening in on the conversation somewhere along the path between the client and server. But having said this, I am not planning use of CPRS outside of my private network, so maybe I shouldn't try to solve this problem for everyone else. I already have a solution working, with an imbedded web browser inside CPRS that looks at documents, finds a URL, and then displays the image. If I use this solution, I will have to turn my http server back on, though I will not allow access to it outside my private network (i.e. my hardware firewall will block outside access). Furthermore, I can print these today. So why am I working on a separate solution? If what I have done so far seems off track, I think I will take a break from this approach for awhile. It does seem that working to secure RPCBroker calls would be a worthwile project. But someone other than me would have to do that. Kevin ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
