Ted: It's in the htaccess file.
Doing a little trolling, Erol? Is that really necessary?
David
Where does that code go? Into what file? An .htaccess file or an ICMS file?
If htaccess, I assume I have to apply that code to the stuff posted by Vaughn in the reply previous to this?
Getting terribly confused now
Hi Ted, I believe you can setup web.config in IIS to do the same.
http://www.isapirewrite.com/ should give you all the info on isapi_rewrite
http://www.15seconds.com/issue/020220.htm will explain a bit more about webconfig.
also try the isapi_rewrite mod for IIS, it allows you to use htaccess.
There is a similar system on microsoft webPI. I believe it can even import apache .htaccess files.
Marcan is in Seattle right now, doing a Microsoft seminar. You could ask him with a tweet.
Cool ok now have it working, thanks. Will be moving everything to https and staying there.
Quote:
Lastly, you also need to find a way to stop people accessing your site via http:// ... that's the bit I haven't worked out yet, although aph3x aparrently has, where is he ??
Quote:
Madfish wrote:
Lastly, you also need to find a way to stop people accessing your site via http:// ... that's the bit I haven't worked out yet, although aph3x aparrently has, where is he ?? :)
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.aphexthemes.com/$1 [R,L]
RewriteCond %{HTTP_HOST} ^aphexthemes\.com
RewriteCond %{HTTPS} =on
RewriteRule .* https://www.%{SERVER_NAME}%{REQUEST_URI} [R,L]
RewriteCond %{HTTP_HOST} ^aphexthemes\.com
RewriteCond %{HTTPS} !=on
RewriteRule .* http://www.%{SERVER_NAME}%{REQUEST_URI} [R,L]
I run a Windows server though - correct me if I am wrong, but .htaccess files don't work on WindoZe? Is there another or different way?
Quote:
Lastly, you also need to find a way to stop people accessing your site via http:// ... that's the bit I haven't worked out yet, although aph3x aparrently has, where is he ?? :)
Quote:
You need to have an SSL certificate installed on the server. If you are using shared webhosting, quite often they have a shared certificate already installed but you may need to look around to find the details.
You need to have an SSL certificate installed on the server. If you are using shared webhosting, quite often they have a shared certificate already installed but you may need to look around to find the details.
To be fully SSL, you can't be pulling resources (eg. images, scripts) from external sites. It's all got to be local or the user will get warning messages (they might not actually be of any security significance, but its ugly and undermines confidence).
Lastly, you also need to find a way to stop people accessing your site via http:// ... that's the bit I haven't worked out yet, although aph3x aparrently has, where is he ?? :)
Yeah, I will implement that extra login file ASAP.
I assume that as I have https on my server already, I could just change the physcial path details in mainfile to start with https instead of http? That way, all web page activity will be over https protecting pages that may contain sensitive data if a user is accessing the site in a cafe or something?
In summary, if I adjust path to https and install the extras\ssl login.php file, my whole site will be over https, correct?
I would have to agree with your user and with Phoenyx - if the target of the form is on the http protocol, the username and password are sent in plain text.
However, if you are using login.php distributed with ImpressCMS, found in extras/ssl, the form action is just 'login.php', which when the page is loaded, will inherit the protocol used to load the page.
1 thing i did adjust in version 1.1, is that when using https protocol, the session cookie is set to secure mode, so in a sense, if you are using https, the cookie will only be sent over https, it will fail if you try to retrieve the cookie via http
As long as the form action goes to a https destination, the password is encrypted. Otherwise not. From what I can see in #1 I would say that the password is send in plain format even though the page is displayed via https.
never tested, but i would think so. you could test that if you have a site on a test pc at home, and then access the site on the lan from a laptop or something whilst using a network packet monitoring tool such as ethereal or something.
if it is, then it only leaves 2 options as far as i can figure.
1. you use SSL over https.
2. you design a client authentication system that a user installs onto his/her pc which then encrypts the password and user data before it is sent by the browser, so you are only transmitting the pw in a hashed form, or encrypted form and the web server then decrypts it before authentication. such a system could be done.
If the login page is viewed over https the password is not sent in the clear and a casual eavesdropper can't get it.
Will - I will look into that extra file - I didn't realise it was potentially that easy.
Vaughn - cool stuff.
All - in order that I can reply to any potential concerns by members of the club for which the website represents, can I check the original question which was : though the login page of https is encrypted itself, is the login password actually sent in plain text across the Internet, or not? I assumed it was not as this is a big problem for our users if using an open wireless Internet cafe or something.
Ta
Ted
the session id is regenerated, also in 1.3 the session cookie key will also be tied to the users IP, browser agent, browser language. if any of those are different, then you'll have to login again.
i also did plan on trying to use private key pairs, where you upload your public key to the site, or have the site connect to a keyserver to retrieve your public key.. then unless you have the private key on your pc, your authentication will fail.
think of pgp encryption methods.