On Sun, 2005-09-04 at 16:17 -0400, Kevin Toppenberg wrote: > Notes below: > > On 9/4/05, Todd Berman <[EMAIL PROTECTED]> wrote: > > On Sun, 2005-09-04 at 11:15 -0400, Kevin Toppenberg wrote:
<snip> > > > 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. > The PChar 'string' is a C style string. The issue with using Call instead of pchCall is that you are getting returned a Delphi string, and (I believe, but am not sure) a Delphi StringList, which uses embedded \r \n, \n, and \r to seperate the string into an array. By getting the PChar return, you are basically being given a byte*, which is what you want, not a TString or whatever is returned by the other calls. You might have to massage the data and play with it a bit to get it to where you would want, but that is where my suggestions below come into play (Not using the RPCBroker to transfer images). The reason I am pretty sure of this, is that the RPCBroker doesn't stop reading on a \0, it keeps reading until a ASCII EOT, #4. However, you could run into issues dealing with the returned PChar and \0, but I would have to think that this is at least a better way to start looking at solving it if you do decide to stay with the RPCBroker. If pchCall gives no joy, I would then look at strCall. Stay away from Call and lstCall, as those are going to def. cause issues. > > > > > > 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? > Our broker is a reimplementation, as we do not have our client implemented in Delphi for various reasons explained earlier on this list. The difference is only in the code that is used to implement it. The protocol itself is the same, and our implementation of the RPCBroker speaks perfectly fine to a FOIA VistA, or VOE, or any other server. So if there is an issue at the end of the day with getting the actual binary data out, it exists in the Delphi implementation, not the protocol itself, or on the server end. > > > > > 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. > I don't believe you should relate the two at all. Regardless of the available access method, if a user with those permissions makes that kind of error, then that outcome is possible. That is a situation where the offending user is the security issue, not http, or https, or apache, or any other piece of software. > 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. > I am fairly certain that https is a pretty reliable method of securing data. I mean, I certainly hope so, because I do far too much banking online for it to not be so :). > 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. > Working on a secure RPCBroker is (again, imo), an absolute waste of time and energy. The way we have solved the security issue has been explained before, but I will briefly go over it real fast. We have the VistA backend server sitting behind all the firewalling, and etc. Then there is a 2nd gateway server that can communicate with the VistA server, and with the internet at large. This is the single point of access inside and outside of the hospital. This 2nd gateway server runs a piece of middleware that speaks SOAP over https (among other secure protocols). So that allows our client to easily be used from anywhere, with https security to all data. There are a lot of reasons this approach is better than the single reason re: security, but that absolutely was a factor in our decision. --Todd ------------------------------------------------------- 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
