RE: suggestion request!

[Jean-Francois Poilpret]

Hi Andrea,   [For HiveMind list readers, sorry for the noise here, but I think this is a general architectural problem that deserves broad discussion and other HiveMind users might be interested too]   OK, I see now. In this case, what you need is not really a Principal (a Principal is not supposed to contain information about printer format, only user information, such as the UserId as you mentioned, except if the printer format is part of the information of the user and that information is not explicitely sent by the client everytime the user logs in).   1st case (simplest): -        you manage the user info (including printer format info) in a centralized way (stored on your DB) and this info can be changed only by an administrator (or kinda). -        Then you can use Principal to store all this info (and HiveLock/SecurityFilter can help you fill in this specific Principal)   2nd case (harder): -        the printer info is completely dynamic (and decided by the user on the client application) -        what you need here (if you do not want to add this info to each of your service methods) is to have some kind of “context passing” (the context would be all the printer format info). -        Normally, Hessian supports this kind of context passing through “Hessian headers”, however, as of hessian 3.0.13 (latest) this does not workL (see my mails on the hessian mailing list to see why) -        In hiveremoting.caucho (0.4.6 and 0.5.0-B3 only), I implemented some kinda “context passing” over hessian without using hessian headers, but using http headers instead. The drawback of this method is you can pass only string context(s), not structured Objects as one would like. This feature has been used in HiveBoard 0.2.0 for checking versions between client and server, you may take a look at it (check for occurrences of RemoteContextHandler in HiveBoard classes). -        What you would have to do is to create, on the server side, a special RemoteContextHandler that would put those context strings in a ThreadLocal so that your services can access them (possibly your RemoteContextHandler would also pre-format these context string into one context object, easier to handel by your services).   I hope this helps you finding your way to your own solution.   Cheers               Jean-Francois     From: Andrea Chiumenti [mailto:[EMAIL PROTECTED] Sent: Monday, September 12, 2005 1:07 PM To: hivemind-user@jakarta.apache.org Subject: Re: suggestion request!   Jean-Francois, Thank you for the prompt reply, but yes, you missed something, I didn't probably explained myself in the proper way. When printing a report I need to know its type (A4, Label, A3, ...) so that user can address it to the right printer, and need to know the user id too, so that only reports belonging to the requireing user are handled. It seems to me that hivelock, that I want to use, only handles the authentication/authorization layer. I hope this can clarify what I missed. kiuma On 9/12/05, Jean-Francois Poilpret <[EMAIL PROTECTED]> wrote: Hello Andrea,   I don't understand why the principal has to be passed by the client. If you use hiveremoting.caucho with hivelock and SecurityFilter (I have done this in hiveboard already) then the only extra info to be passed by the client is the session identifier. This session identifier is stored in a cookie so it is transparent for the service calls. In this case, the authentication happens only once and occurs through normal http athentication scheme (hiveremoting.caucho already supports this).   Does this answer your problem, or is there something I have missed?   Cheers   Jean-Francois   From: Andrea Chiumenti [mailto:[EMAIL PROTECTED]] Sent: Monday, September 12, 2005 12:26 AM To: hivemind-user@jakarta.apache.org Subject: suggestion request!   Hello,  I wanto to create a web project that has a service named AsynchronousRemotePrinting. This service grants to you to directly send reports to your local printer simply clicking on a web-link on your browser, this will be a feature of an OS project that will make heavy use of hivemind(and hivetranse) and tapestry. The way i can make possible to print on the user local printer from a web browser is relatively simple: 1) When the user log into the application for the first time he starts a client application via webstart, and identifies himself. 2) Asking for a report to print ( click on a link on the browser), means to save the report by email or webdav. 3) The  webstart application has a chron job that periodically asks to the server if the user has some report to print 4) If yes, then, throught Hessian, the local application downloads the report and prints it to the preferred printer. Now my implementation problem is this: 1) If I implement the service as an hessian service, I can define clean service methods (no user credentials are requested as parameters) but the service will remain tied to caucho (the service class can be only a caucho servlet, since in methods I have to distinguish between users to transmit the right reports). 2) If I don't want my service to be strongly tied to caucho the I have to adopt the hiveremoting.caucho solution, but then I have to transimt somehow the principal as method parameter. I also think that principal has to be validated at each service call since it doesn't come from server side,. So I don't know what should be a better solution: caucho tiding or Principal passed as parameter ? Currently I've not been able to think to other possible solutions and I'm actually more interested in the caucho heavy tie  solution. I'd like to have some suggestion or opinion if possible. Thanks in advance, kiuma