in reply to Re^2: http::daemon::threaded - soap?
in thread http::daemon::threaded - soap?

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

Replies are listed 'Best First'.
Re^4: http::daemon::threaded - soap?
by ethrbunny (Monk) on Aug 04, 2007 at 05:03 UTC
    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.
[reply]
Re^4: http::daemon::threaded - soap?
by ethrbunny (Monk) on Aug 04, 2007 at 05:39 UTC
    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'.
[reply]

In Section Seekers of Perl Wisdom