All-

I am working on Geeklog 1.3.7 with the new security update that just came out and Menu Plugin 1.2. Our security folks have asked that I get the login part of Geeklog encrypted as soon as possible so passwords aren't being sent in cleartext. So I got SSL running on the site and I'm looking for clues on how to get Geeklog to work with it.

The first applicable reference I found that relates to this appears here. I followed the advice in the response to this question by changing my $_CONF['site_url'] variable from http://somegeeklog.com to '' as suggested and ended up with Geeklog not displaying anything on the page at all.

So, I scratched my head for a bit and changed the $_CONF['site_url'] back and started poking around to find the code that displays the actual form thinking I could change the form to post to https://somegeeklog.com/users.php instead of http://somegeeklog.com/users.php. And thanks to some help from TomW and others I located the places where I could edit the Login Form. I changed it in two places. The first in /plugins/menu/functions.inc (thanks TomW), I changed '  .  $_CONF['site_url']  .  ' in the form part of the MNU_userMenu function to https://somegeeklog.com/users.php. And the second place in /public_html/layout/clean/users/loginform.thtml. The change to loginform.thtml seems to work great, but when users login using the form displayed by the Menu Plugin after my change, the system comes back with a server not found error because URL bar shows it is trying to point to http://somegeeklog.com/,http://somegeeklog.com. If I type the actual URL back in and go back I find that I am authenticated to the system, however, and I can get into everything I am supposed to.

My guess is that I'm simply trying to do something that I shouldn't be (or I'm trying to do it the wrong way) and I should sit on my hands. Anyway, sorry for the long note. I am not the sharpest tack in the wall and also not a PHP wiz. Any help would be greatly appreciated. Thanks much.

Menu Plugin Version I am using is 1.61

This would be a good feature request. Add some code to the login and set a config.php variable just for that so users who have SSL access could use it to protect the logins. This would go a LONG way towards bringing GL a cut above the rest in security.

---
L. Whitworth
www.finiserv.com

---

L. Whitworth

A temporay solution, if you don't mind all pages and requests being encrypted, would be just to set you're $_CONF['site_url'] = "https://sitename.com/". Passwords, along with everything else, would be encrypted in this case. Geeklog runs fine this way.

Yeah, I'm afriad it might be the only thing I can do. If I do that, though, what will geeklog do with a request to http? Since there are links to this site all over the place I'm a little bummed about having to force https and then break the http link and create a bunch of broken links out there. But in the absense of alternatives, I guess that maybe the only choice I have. Thanks!

The other thing I thought of was removing the login form from the frontpage and replacing it with a link to loginform.thtml in my theme folder. Would this work? How would I link to that form? Is it as simple as pointing to: http://<somegeeklog>/<pathtolayout>/loginform.html ? Thanks again!

Nope! =) http://<somegeeklog>/<pathtolayout>/loginform.html definately doesn't work.

At least in 1.3.7 Geeklog handles this just fine. Links to http://whatever.com will still work. They should either get redirected to https://whatever.com or just work with all links away from the page going to the encrypted version. Not sure if 1.3.7sr1 handles this differently...? I'm not sure, but this could actually be a small security hole since a user could, theorectially, still pass their password and username unencrypted. That's more questions than answers, maybe someone like Dirk could fill in the blanks?

What about removing anoymous permissions on the login block then creating a https login link that opens a regular html page in a pop-up with the login form that submits the data via https then automatically closes, thus allowing GL to reload to a non-secure page after the data is processed?

---
L. Whitworth
www.finiserv.com

---

L. Whitworth

In previous version 1.3.6 a setting to: $_CONF['site_url'] = ''; was functioning. If I use https, all links was https, if I use http, all links was http. But in new version 1.3.7 index.php was changed to refresh to /index.php and when "site_url" is empty string, browser is in infinite loop. Is it possible to change behavior of the index.php to old state? -- Rado1 rado@rado1.sk

The refresh was added to fix the problem where the site wasn't recognizing people if they typed in a different URL format than was in config.php. For example, if you placed www.domainname.com in the config file but a person typed in domain.com, the system wasn't picking him up. Some others were experiencing a looping problem too, but I thought Dirk fixed this in 1.3.7sr1. Try upgrading to that version instead and see if it solves your problem.

If it doesn't, perhaps my recommended cookie bug fix will. I commented out the refresh code in index.php and then changed the cookies in five files so all parameters are set now. Haven't had any problem with side pages since doing this. I don't need the refresh workaround to recognize those who use the "other" URL format. Let me know if you need more detailed instructions.