[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proof of concept structs for 2.0

Chris Travers wrote:


So if we worry about that we have to track it.  This suggests to me
the following modification:

struct LedgerSMB::Session, {
    id     => '$',
    token  => '$',
    dbclient => '$', # Pg type inet, connection of client connecting to Pg
    type => '$', #type of session (web, etc)
    auth_module => '$', #name of auth module
};

This could be subclassed for web interfaces by also adding a remote_addr field:
struct LedgerSMB::Session::Web, {
    id     => '$',
    token  => '$',
    dbclient => '$', # Pg type inet, connection of client connecting to Pg
    type => '$', #type of session (web, etc)
    auth_module => '$', #name of auth module
    remote_addr => '$', #type inet, remote address from web server perspective
};


Chris, is it really necessary to subclass for the web interface?
I would think that including remote_addr would be valid for all interfaces, even if it just showed the loopback address when run on a local machine. unless the transport mechanism was unix sockets or mmap in which case it should contain a value that shows that. (eg: unix or mmap) In the event of a problem I would think that this information may help track the cause. eg: an attempt to connect using a tcpip layer when user is connected using mmap. 
This is all conjecture, and I may be WAY off the mark :-)

David G