The IP number is one of the piece of information assembled together to generate 
a session id, afterwards this session id is stored in a cookie. At every 
request the cookie is fetched from the browser to establish the session and it 
goes into a key made by session_id,ip_number to read the data from the 
database. I wonder if it's absolutely necessary to include the IP in the key. 
The MD5 session id should be reasonably safe as to avoid key duplication for 
different sessions. The MD5 sum is composed already by a pretty composite set 
of data.


set sessionIDkey "$uniqueID[clock clicks][pid]$args[clock 
seconds]$scrambleCode[get_entropy_bytes]"
return [::md5::md5 -hex -- $sessionIdKey]

where uniqueID is generated by mod_unique (check this module is loaded)

and the entropy bytes are generated by /dev/urandom (I guess this is 
incompatible with Windows)


do we need the IP number to achieve reasonable uniqueness of the key in session 
table?


 -- Massimo


________________________________
Da: Brice Hamon <normandvik...@gmail.com>
Inviato: venerdì 2 febbraio 2018 05:22
A: Massimo MANGHI
Cc: Rivet_dev
Oggetto: Re: Session issue behind load balancer

Hi Massimo,

No please don't wait as I think Damon's Apache configuration will solve the 
issue and won't require a Session's package modification.
We will have to try first in staging.

However I wonder what happens when a mobile user change tower and if the IP 
could change. Then a change in the Session package would be required and we 
would submit it.

Thank you

Brice.


On Thu, Feb 1, 2018 at 5:18 AM, Massimo Manghi 
<massimo.man...@unipr.it<mailto:massimo.man...@unipr.it>> wrote:
I rolled out a 3.0.1 without waiting for this interesting new feature of the 
Session package, but if you feel you can make it in a definite time I will wait 
with pleasure for your contribution and then include it into this release

 -- Massimo


On 01/31/2018 09:10 PM, Brice Hamon wrote:
Thank you Damon.

This is an interesting suggestion. I'll look into it and report.

Thanks again,
Brice.



Reply via email to