Another issue seems to be that because cookies are protected under SSL, once the client is directed back to the non-SSL site they cannot access any cookie created during the login. This is easily disabled but I'm wondering if it is wise to do so.

When a server sets a cookie in an HTTP response, it can optionally be marked 'secure' - if so, the browser will only return the cookie on subsequent requests IF the connection is over HTTPS.

Cookies may be marked secure or not independently of whether the request is HTTP or HTTPS. It sounds like in your case, the server is adding the 'secure' flag.

More info available here: http://www.cookiecentral.com/faq/#3.3

Good luck!

-- Jim R. Wilson (jimbojw)

On 8/11/07, Michael B Allen ioplex@gmail.com wrote:

Hi,

I have a plugin for authenticating clients against the central directory on large Intranets. In this environment it is not ok to use directory passwords within an insecure login form. These passwords must be encrypted.

I would like to create a plugin that requires HTTPS when calling SpecialUserlogin with action=submitlogin.

Right now I'm looking at somehow affecting the result of $titleObject->getLocalUrl so that the https:// protocol may be injected. I have not quite determined how to direct the client back to the non-SSL site. Of course Location headers are an option [1] but I am worried that they might interfere with Single-Sign-On and other "autoAuthenticate" apparatus and in general they should, in theory, not be necessary.

Another issue seems to be that because cookies are protected under SSL, once the client is directed back to the non-SSL site they cannot access any cookie created during the login. This is easily disabled but I'm wondering if it is wise to do so.

Does anyone have some comments to add about this problem?

Mike

[1] I am aware of the following page but I would explore all options.

http://meta.wikimedia.org/wiki/Help:Configuration_tips_and_tricks#HTTPS_on_L...

---

MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Well this is what I came up with. Still uses a Location header after the user logs in but it targets the login form action more specifically and the code is relatively simple. Most of it deals with simply coming up with a URL to redirect the client to after they login so that they don't have an opportunity to branch off into https land. And most importantly it seems to work well.

Of course I'd be interested if anyone thinks they can improve on this or if they endorse the methods used.

Mike

<?php function userLoginForm($template) { global $wgServerName;

$action = $template->data['action']; $template->set('action', 'https://' . $wgServerName . $action);

unset($_SESSION['returntourl']); $returnto = 'Main_Page'; if (isset($_GET['returnto'])) { switch ($_GET['returnto']) { case 'Special:Userlogin': case 'Special:Userlogout': break; default: $returnto = $_GET['returnto']; } } $title = Title::newFromText($returnto); if ($title) $_SESSION['returntourl'] = $title->getFullURL(); } function autoAuthenticate($user) { if (isset($_GET['title']) && isset($_GET['action']) && $_GET['title'] == 'Special:Userlogin' && $_GET['action'] == 'submitlogin') { if (isset($_SESSION['returntourl'])) { global $wgCookieSecure; $wgCookieSecure = false; header('Location: ' . $_SESSION['returntourl']); unset($_SESSION['returntourl']); } }

return TRUE; } $wgHooks['UserLoginForm'][] = 'userLoginForm'; $wgHooks['AutoAuthenticate'][] = 'autoAuthenticate'; ?>

Is there any way to do this in the server configuration, rather than in MediaWiki? Just tell the server to always use https for that particular page. (This may well be impossible, especially since the request is initiated by the user, not the server, but if it's possible, it would be easier than hacking MediaWiki.)