ok, i got the point on having a hard time implementing case-1 with web2py. Please humour me, what I didn't got over those kind of requirements is basically.......case-1 adds 0% security. If there is a man in the middle, he can "scoop" the cookie just as he would scoop the password in the case of no HTTPS at all on the site (so, user A gets access to whatever B can see). Is it just to "reassure" the majority of dumb users with a nice padlock on the login page or it gives some kind of *actual *protection?
PS: leave aside the fact that SSL certificate allows your site to be "trustworthy" (user A knows that the site at http*S*://example.com is managed by Yarin). If you are trustworthy for only *some *of the urls, you publish something at http*S*://example.com and something at http://example.com, and users need to know *in advance* that your login is on a http*S*, *and pay attention before hitting "login"* to avoid a simple dns poisoning attack (i.e. for their computer http://example.com points to the site managed by a - very bad - Niphlod, that can fake whatever is there on Yarin's http*S*://example.com/login on Niphlod's http://example.com/login). That is a nice "theoretical" security gain (Niphlod can't have a working http*S*://example.com/login because he doesn't get to know the private key of the certificate, and users are at least "warned" that the certificate is not right) but with "normal" users (click everything shiny? yes!, install this toolbar? yes! format the c: drive? yes!) means more or less 0% achieved security (given that they hardly "know in advance" that a padlock on the page is "required" to be there). Am I missing something ? --
