Forum Moderators: buckworks
I finally got my SSL certificate installed but Iīm not sure whatīs the best approach: call the login page through [,...] and, therefore, everything after it takes the same bus; or, forcing http back, right after the login.
What you guys do?
Thanks
phoenix_fly
In fact, I think this might be a solution. And, to avoid the annoying message, I can make the https login screen appear in a small pop-up, just like our friends browsers do.
But, are you sure the traffic of username/password is the major critical point? What about session hijacking? My memberīs are pages get the cookie (a md5 hash, made of aleatory values, not username or pw) everytime. If someone "listens" to it, and comes in with that disguise, it would be a problem.
What do you think about it? Am I forgeting sth?
Thanks
phoenix_fly
read this excellent post [webmasterworld.com...]
Thanks for the link. It read it and in fact they talked exactly about the same issue weīre dealing.
I am almost implementing the SSL login-only, but two points arenīt 100% clear yet for me:
1) they said the login form doesn't need to be printed in a https page. I think it needs, doesnīt it?
2) After the login, is it correct that the transition to a non-secure page only generates that annoying message if it is a form-submitting link? Regular links through "a href" do not generate it and make the transition smoothly?
André
Iīve tested the #2 and the browser does show the message box. The situation I tested was the following:
1) login.cgi - the login form is called through https.
2) The user fills in username and pw, that are submitted, also, to login.cgi through https
3) login.cgi - after the verification routines, redirects the user to a non-https members start page. [Pow, message box appears!]
I was thinking of making this members start page still through https, and put in it a <meta> redirect to a non-https start page. You guys think itīs a good workaround? Is there another way? (this seems too brute force...)
Thanks
phoenix_fly
It also depends what information you need to protect, if it is something critical or any personal information is sent back and forth I would put the whole thing under https.
Do you require them to login to just browse the site?
In this site, the login is required to access paid resources that the non-paying members don't get. Also, there is a administrative section wich has some dangerous facilities to an evil visitor.
I am willing to settle with the cookie-ip scheme, having ssl in the login only, because itīs not a site for an all-hated financial institution and people seem to rely on this scheme for medium-high security applications. But the problem is how to throw back to http without that annoying message from the browser...