There’s no real reason to include IP address. Anything random will do. I always use a combination like this:
set s [clock seconds][pid][clock clicks][info cmdcount][info hostname] Any of those will do, so a bunch of them together is probably overkill, but that should produce a significantly random string to use as a session identifier. D > On Feb 5, 2018, at 10:28 AM, Brice Hamon <normandvik...@gmail.com> wrote: > > Hi Massimo, > > That was my point. > > In our application, we had to disable it because of the load balancers > introduction. > > Damon's proposal will most likely solve the problem, but not entirely for us > as rivet powers also mobile apps and IP may change as the users move. > > I think we should by default enable it so we keep backward compatibility, > and add a new session call to disable the IP check. > > That way the session package is more flexible. > > My 2 cents. > > Thank you, > Brice. > > > > > On Mon, Feb 5, 2018 at 1:41 AM, Massimo MANGHI <massimo.man...@unipr.it> > wrote: > 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> > 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. > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
