Hi Mike, On Wed, Sep 25, 2013 at 2:16 PM, Mike Willbanks <pen...@gmail.com> wrote:
> Each and every type of prevention measure has consequences and not only > that but MAJOR consequences. If you are detecting IP changes you rule out > most if not all major proxy networks that exist. While not first of mind; > when handling this you can easily remove the old session without properly > transitioning to the new. This is an option based off of individual > application vs. a language option or construct. There are a ton of > different measures that you might take based off of changes to the end user > data. I think this would be a poor idea in the long run due to the > consequences that you may incur. The more I get this kind of response, the more I feel we should introduce this feature as session module optional feature. Regenerating session ID should not be any problem as long as session ID is cookie based, save handler lock session data while it is used. As far as I know, the only faulty save handler is mm save handler. (I would like to implement lock in mm, but it's low priority for me. When TranSID is enabled, it would cause problems due to cached pages.) The best practice of the session ID management is regenerating session ID when events happen. Mandatory one is login event. Web programmers must regenerate session ID to make sure session safety at login. IP address change is one of the event, even though it's not mandatory. There is PHP framework called Piece Framework that has option regenerate session ID for every request to achieve maximum session ID security, for example. If regeneration of session ID causes misbehavior, then it is a bug including users fault. I think if I disable this feature when TranSID on and/or expire is not 0, then there would not be issues. Unless web programmers use session ID for CSRF protection, etc. Anyway, I'll start from documentation. If there are any comments, I'll appreciate it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
