Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: http::daemon::threaded - soap?

by renodino (Curate)
on Aug 03, 2007 at 15:21 UTC ( #630535=note: print w/ replies, xml ) Need Help??

in reply to http::daemon::threaded - soap?

Sorry, I haven't thought that far ahead (yet). I'm still working on improvements to the apartment threading infrastructure (esp. performance).

However, once a connection is established, H::D::T::WebClient just forwards stuff to a H::D::T::Content handler based on a regex, so if you can collect the Content-Type for your SOAP, then write a content handler module to accept/process the SOAP request and generate the XML responses, you should be on your way. (I don't know how any of the Perl SOAP modules will play with that environment)

Also keep in mind that H::D::T is still very young, and the current CPAN version is functionally limited (No SSL, primitive session support, etc.)

update: fixed minor typo

Perl Contrarian & SQL fanboy

Comment on Re: http::daemon::threaded - soap?
Re^2: http::daemon::threaded - soap?
by ethrbunny (Monk) on Aug 03, 2007 at 16:49 UTC
    What Im mostly concerned about is restricting access to the functions. When I implemented this scheme in Axis2 I did a "create a nonce, have both sides encrypt it with a known key and compare. If they're equal then permit access to the functions." The problem Im trying to solve is how to know when a new connection is made so I can create a new nonce - and similarly to know when the existing connection has been properly 'authenticated' or not.

    Its all 'session' management. If I can get cookies working I can probably get something going.
      Alas, H::D::T's session mgmt is largely non-existant (tho I'm working on more robust support for another project). It does capture cookies, but you'll have to implement your own H::D::T::Session and SessionCache objects. You may find the classdocs more helpful than the CPAN POD to guide you. But I definitely need to put together a tutorial.

      You also mentioned "memory management issues" in the OP. Care to elaborate ?

      Perl Contrarian & SQL fanboy
        RE: Memory management - I will be communicating with this 'daemon process' 1 or more times per day for the next several years. Its imperative that whatever session management scheme I can find / create / begborrowsteal be rigourous about keeping each session and its associated variables 'tidy'. IE delete every allocation, handle or otherwise.

        Each time I start a 'session' I need to know that it has cleaned up the previous one. I can't count on the server hardware at each installation (there will be 3-500 separate machines at disparate, remote locations) being able to reboot if a process gobbles up the memory.

        On a very simple level I need to know that if I authenticate a given session that someone else can't reuse my session 'handle' - that each new session has its own security separate from the others. As I said in my other reply I will be using this solution to transport HIPAA protected information. Security has to be strong from the outset.
        My thinking of late has been that I will do as I did in Java and have two 'authenticate' functions: one to ask for the nonce and one to return it. If its correctly encrypted then the reply to the second will be a connection 'handle' that gets passed back with every subsequent function call as a means of saying "this is an authenticated call". The same handle will be a lookup to an internal hash of whatever session params I might want. Ultimately (when I can get it working) this param is a cookie. (Still looking for a good example (read "one that I understand") on how to use cookies with Soap::http::transport::daemon).

        The trick that I haven't got sussed out yet is how to know when the session is 'closed'. How to let the server process know when it can delete the memory. The fact that Perl doesn't really allocate memory ala C++ makes this a different problem. The trick might be to make every soap call 'self enclosed' in that nothing is left 'dirty' after it closes. That way if I don't call some 'end session' call to invalidate the handle I don't have to worry about someone from the 'outside' reusing the session handle and getting the same variables.

        Now that Im typing this out Im thinking that maybe the way to avoid a 'man in the middle' attack of someone sniffing the connection handle and reusing it is to have the original nonce get incremented somehow with every function call and sent back as a param. I will only need to support one 'session' at a time and if both client and server know how to re-create the original session handle then I can still get to any saved session params.

        Or maybe I just support one 'session' at a time. Any successful authentication erases any pre-existing session info...

        Hmm.. in retrospect this sounds way over-architected but it does alleviate the need for some sort of memory manager or garbage collector. Get rid of the need to juggle multiple sessions and worry instead about keeping the one session clean and safe from the next one.

        Further rambling: I need to read more about SSL and Soap::Lite. Not much is available. Maybe this is all moot.

        Playing 3 days of golf in 100+ degree weather has effected my brain. Both positively and... whats that word... the other way... umm..oh yeah.. 'not positively'.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://630535]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (5)
As of 2014-10-23 01:37 GMT
Find Nodes?
    Voting Booth?

    For retirement, I am banking on:

    Results (123 votes), past polls