On Thursday, June 16, 2011 6:43:42 PM UTC-4, blackthorne wrote: > > > On Jun 16, 11:08 pm, Anthony <abas...@gmail.com> wrote: > > On Thursday, June 16, 2011 6:02:00 PM UTC-4, blackthorne wrote: > > > > > Anthony: I don't really understand how would that solve the problem. > > > The problem has to do with transmission of the session cookie in a non > > > secure channel. Regenerate it won't solve the problem. > > > > It will solve the problem of transitioning from an insecure/pre-login > > session to a secure/post-login session, which is a separate issue. > > > I see you assume that the pre-login established session is the same > after login. I consider them as 2 different sessions, so yes > regenerate=True as you say is what I assume that should be the default > behavior when creating an authenticated session.
Are you saying that once the user logs in, any existing session they had should be erased and a new one started? I don't think that's how it works now, and I'm not sure that would always be the thing to do, but maybe it should be an option. I was just suggesting regenerating the session id, but keeping the session itself. > > > We need to > > > enforce not to allow the transmission of authenticated sessions threw > > > non secure channels. I think this should be the default behavior. > > > > I'm not sure the framework should absolutely require SSL in order for the > > > auth system to work at all. > Using any sort of method, providing authentication is more than just > saying who you are which is technically the only thing you are doing > when transmitting a session cookie in a non secure channel. it's about > proving that you are who do you say. While sending a username, > password to a website the user is trusting in the best practices on > handling those credentials safely. Those expectations should > be met by making the possible to prevent, at least, the publicly known > "cheap" attacks. > So, I'm not against the possibility of allowing non secure channels, > just defending this behavior as the one I consider that should be > default. I hear you. Do you have a specific proposal for how auth and post-login routing should work? If a request comes in and the session includes an auth user, should web2py reject/redirect the request if it's not over SSL (at least that would be the default behavior, perhaps with the option to configure auth to allow non-secure sessions)? Anthony
