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
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
