Menu
▾
▴
Re: [ebxmlms-develop] JMS receiver
|
From: Patrick Y. <kc...@ce...> - 2003-06-05 08:23:20
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> <blockquote type="cite" cite="mid...@s-..."> <div><span class="644313705-05062003"><font face="Arial" size="2">What are the technical and security reasons for not allowing this? Technically, if I write a MessageListener that goes berserk, it's my fault, like any other plugin. Security-wise, if I have authentication turned on, I have to know the username/password before I can register my server-side MessageListener, so that's not a problem either.</font></span></div> <div><span class="644313705-05062003"></span></div> </blockquote> <br> The technical reason hold when using Hermes in ASP mode. Consider Hermes set up and allowing the client to connect, the implementation of MessageListener is submitted by the client, and thus the Hermes server does not have any idea about the class definition of the implementation. After object serialization of the implementation, Hermes server even cannot reconstruct the MessageListener implementation.<br> <br> I agree that authentication is solving the security problem. But, to run code from remote is always sensitive. The current authentication mechanism is the least secure way.<br> <br> <br> <blockquote type="cite" cite="mid...@s-..."> <div><span class="644313705-05062003"><font face="Arial" size="2">I just want to bypass all of the built-in MessageListener stuff (which I find rather confusing), and simply use my own server-side MessageListener.onMessage() which Hermes calls for all messages to be delivered to clients. Although you say that "<font face="Times New Roman" size="3">any MessageListener implementation sumbitted to Request will be "interpreted" as either MessageListenerImpl or ClientMessageListenerImpl in Hermes server</font>", my server-side MessageListener is clearly neither of those. Hermes is presumably not being strict enough in figuring out what kind of MessageListener it is dealing with, which is why I'm suggesting removing getClientUrl() from MessageListener and adding a UrlMessageListener (maybe a better name would be ClientMessageListener) interface with getClientUrl(). This will make the division between the different kinds of MessageListeners clearer, and force Hermes to do the right thing: if it's not a ClientMessageListener, just call its onMessage(), else do all the stuff you describe.</font></span></div> <div><span class="644313705-05062003"></span> </div> <div><span class="644313705-05062003"><font face="Arial" size="2">I'd also like to be able to create a Request without specifying a MessageListener at all, and letting my server-side MessageListener accept all the responses, but I can't remember if you've fixed that one already.</font></span></div> <div><span class="644313705-05062003"></span></div> </blockquote> This is possible. But still, we have to consider the effect to ASP mode (our common use-case). Maybe again, a hook should be used to deal with any customized MessageListener first. But the hook should be per-AppContext. Any idea?<br> <br> <br> <blockquote type="cite" cite="mid...@s-..."> <div> </div> <div><span class="644313705-05062003"><font face="Arial" size="2">I suspect my version of Hermes may have diverged slightly over the last few weeks. </font></span><span class="644313705-05062003"><font face="Arial" size="2">As soon as you give me CVS access, I'll download the latest version and try my MessageListener again. (The nightly build seems to have disappeared from the download page.)</font></span></div> <div> </div> </blockquote> Our mistake. Will add that back soon.<br> <br> Regards, -Patrick<br> </body> </html> |
