Chris Travers wrote:
On Sat, Mar 20, 2010 at 7:25 PM, David Godfrey <..hidden..> wrote: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.dbclient is the remote address from the perspective of the db. For a web app, this is the web server's ip address. For a thick client, this would be the thick client's ip address. Basically, this tells you where the LedgerSMB installation is. remote_addr is the remote address from the perspective of the web server, Presumably this would be applicable to any other middleware environment as well, It tells you where the user is, independent of the installation. Does this make more sense?
Fairly much as I thought, I would still propose that remote_addr should be present for all client types, as you could well have, for example a thick client that served an unusual interface; maybe a fully automated multi point warehouse distribution system (think fedex) that automatically raises invoices in lsmb. in this case you might use the remote address to indicate which one of your processing points (eg:fedex truck loading bay scanner) raised the invoice.
I know this is a highly contrived example, but other real world examples would be possible, such as a client that acts as a gateway to wireless devices used for updating inventory and raising Purchase Orders
David G