Re: Session issue behind load balancer
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 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 > 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 > 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 > 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
Re: Session issue behind load balancer
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 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 > *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 > 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. > > > >
Re: Session issue behind load balancer
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 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 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.
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 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. >> >> >>
Re: Session issue behind load balancer
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
Re: Session issue behind load balancer
Thank you Damon. This is an interesting suggestion. I'll look into it and report. Thanks again, Brice. On Wed, Jan 31, 2018 at 3:09 PM, Damon Courtney wrote: > Not a bad idea, I meant. :) > > Damon > > > > On Jan 31, 2018, at 2:02 PM, Damon Courtney wrote: > > > > Wouldn’t you want to check the X-Forwarded-For header and use the user’s > real IP address instead? Not that your request isn’t valid, but you > generally want to ignore the IP address of your proxy and instead get the > real IP. Especially in your logs. You can make Apache do it automatically > with something like this in your config: > > > > > >RemoteIPHeader X-Forwarded-For > > > > > > Then Apache will pick up the header and use the real IP when logging and > everywhere else, including what Rivet sees in its environment. > > > > Proposing a patch to the session package is not a idea either. :) > > > > Damon > > > > > >> On Jan 31, 2018, at 1:59 PM, Brice Hamon > wrote: > >> > >> Hi guys, > >> > >> We ran into a small problem and wanted to share our findings. > >> > >> We introduced http load balancers upstream of our apache servers to > balance the requests. > >> > >> The result of this is that new user session were created randomly and > that was an issue for us. > >> > >> The session package does a look up by IP and sessionID to identify a > given user. > >> But with the load balancers, the incoming IP is always the IP of one of > the LB. > >> > >> So Rivet session was creating new session for that user, who was > already logged in. > >> > >> We made a quick hack to disable the IP check and that solved the issue. > >> We could have made the request sticky but we didn't want that in > production. > >> > >> So should we make this session lookup by IP and sessionID optional with > some type of flag? > >> > >> Thank you > >> Brice. > > > >
Re: Session issue behind load balancer
Not a bad idea, I meant. :) Damon > On Jan 31, 2018, at 2:02 PM, Damon Courtney wrote: > > Wouldn’t you want to check the X-Forwarded-For header and use the user’s real > IP address instead? Not that your request isn’t valid, but you generally want > to ignore the IP address of your proxy and instead get the real IP. > Especially in your logs. You can make Apache do it automatically with > something like this in your config: > > >RemoteIPHeader X-Forwarded-For > > > Then Apache will pick up the header and use the real IP when logging and > everywhere else, including what Rivet sees in its environment. > > Proposing a patch to the session package is not a idea either. :) > > Damon > > >> On Jan 31, 2018, at 1:59 PM, Brice Hamon wrote: >> >> Hi guys, >> >> We ran into a small problem and wanted to share our findings. >> >> We introduced http load balancers upstream of our apache servers to balance >> the requests. >> >> The result of this is that new user session were created randomly and that >> was an issue for us. >> >> The session package does a look up by IP and sessionID to identify a given >> user. >> But with the load balancers, the incoming IP is always the IP of one of the >> LB. >> >> So Rivet session was creating new session for that user, who was already >> logged in. >> >> We made a quick hack to disable the IP check and that solved the issue. >> We could have made the request sticky but we didn't want that in production. >> >> So should we make this session lookup by IP and sessionID optional with some >> type of flag? >> >> Thank you >> Brice. > - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Session issue behind load balancer
Wouldn’t you want to check the X-Forwarded-For header and use the user’s real IP address instead? Not that your request isn’t valid, but you generally want to ignore the IP address of your proxy and instead get the real IP. Especially in your logs. You can make Apache do it automatically with something like this in your config: RemoteIPHeader X-Forwarded-For Then Apache will pick up the header and use the real IP when logging and everywhere else, including what Rivet sees in its environment. Proposing a patch to the session package is not a idea either. :) Damon > On Jan 31, 2018, at 1:59 PM, Brice Hamon wrote: > > Hi guys, > > We ran into a small problem and wanted to share our findings. > > We introduced http load balancers upstream of our apache servers to balance > the requests. > > The result of this is that new user session were created randomly and that > was an issue for us. > > The session package does a look up by IP and sessionID to identify a given > user. > But with the load balancers, the incoming IP is always the IP of one of the > LB. > > So Rivet session was creating new session for that user, who was already > logged in. > > We made a quick hack to disable the IP check and that solved the issue. > We could have made the request sticky but we didn't want that in production. > > So should we make this session lookup by IP and sessionID optional with some > type of flag? > > Thank you > Brice. - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
