ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67178
|
Mon Jan 30 09:31:51 2012 |
| Christof Hanke | hanke@rzg.mpg.de | Question | Linux | 2.9.0 | Re: el cheapo LDAP binding | Hi Christian,
I have also the need to do auth on the webserver, but I tried to integrate it into elogd as far as I could.
However, I do not try to set a special cookie to set the username, but always use
"X-Forwarded-User". Like this, every request is authenticated by the webserver in front.
If that's not too heavy for you, try out the applied patch.
HTH,
Christof
PS:
@Stefan:
If you are willing to integrate this into the official tree,
I can provide some docs for it (like setting author
directly etc.)
-----------------------------------------------------------------
Christof Hanke e-mail hanke@rzg.mpg.de
RZG (Rechenzentrum Garching) phone +49-89-3299-1041
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut für Plasmaphysik (IPP)
Christian Herzog wrote: |
Hi all,
we would like to hook elog to our LDAP server. Instead of writing a full-featured LDAP auth module for elog, I have the following idea: use Apache's LDAP module to require LDAP auth for a single logbook:
<Location /elog/admin>
Use PhysLDAP
Use RequirePhysLDAPGroup isg
RewriteEngine On
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader add X-Forwarded-User %{RU}e
</Location>
the two Use statements are Apache macros that define our LDAP settings. The last 4 lines are necessary for Apache to pass on the logged in user to the proxied elog (ends up in ENV X-Forwarded- User).
In elogd.c, I added
/* extract REMOTE_USER */
if ((p = strstr(request, "X-Forwarded-User:")) != NULL) {
p += 17;
while (*p && *p == ' ')
p++;
strlcpy(remote_user, p, sizeof(remote_user));
if (strchr(remote_user, '\r'))
*strchr(remote_user, '\r') = 0;
char sid[32];
/* get a new session ID */
sid_new(NULL, remote_user, (char *) inet_ntoa(rem_addr), sid);
/* set SID cookie */
set_sid_cookie(NULL, sid);
// TODO: set lbs!
}
to process_http_request in order to extract the LDAP login. I have managed to populate the author field with remote_user, but what I'd really like is to write a cookie containing this login name so that session handling kicks in. You can see that I attempt to write a cookie, but elogd segfaults at set_sid_cookie() (gdb backtrace:
set_cookie (lbs=0x0, name=0x483b22 "sid", value=0x7ffffffd7590 "4831386B7B333A99",
global=0, expiration=0x7ffffffd7300 "")
Would anyone be willing to help me with this? I'm not at all familiar with the program flow in elogd and my C is a bit rusty...
thanks,
-Christian
--
Dr. Christian Herzog <herzog@phys.ethz.ch> support: +41 44 633 26 68
IT Services Group, HPT H 8 voice: +41 44 633 39 50
Department of Physics, ETH Zurich
8093 Zurich, Switzerland http://nic.phys.ethz.ch/
|
|
Attachment 1: elogd-addwebserverauth.patch
|
--- trunk/webservices/ELOG/elog-2.9.0/src/elogd.c 2011/10/20 14:36:27 3247
+++ trunk/webservices/ELOG/elog-2.9.0/src/elogd.c 2012/01/30 08:14:32 4130
@@ -37,6 +37,7 @@
char listen_interface[256];
char theme_name[80];
char http_host[256];
+char http_user[256];
char _param[MAX_PARAM][NAME_LENGTH];
char _value[MAX_PARAM][NAME_LENGTH];
@@ -8534,7 +8535,7 @@
if (old_pwd[0] || new_pwd[0]) {
if (user[0]) {
- if (stristr(auth, "Kerberos")) {
+ if (stristr(auth, "Kerberos") || stristr(auth, "Webserver")) {
if (strcmp(new_pwd, new_pwd2) != 0)
wrong_pwd = 2;
} else {
@@ -12677,6 +12679,12 @@
return 0;
}
+ /* if we have outsourced the authentication, use external username */
+ getcfg(lbs->name, "Authentication", str, sizeof(str));
+ if ( stristr(str, "Webserver")) {
+ strncpy(user,http_user,sizeof(user));
+ }
+
/* check for full name */
if (!isparam("new_full_name") || *getparam("new_full_name") == 0) {
sprintf(str, loc("Please enter \"%s\""), loc("Full name"));
@@ -13247,7 +13255,7 @@
rsprintf("<tr><td nowrap width=\"15%%\">%s:</td>\n", loc("Login name"));
getcfg(lbs->name, "Authentication", auth, sizeof(auth));
- if (stristr(auth, "Kerberos"))
+ if (stristr(auth, "Kerberos") || stristr(auth, "Webserver"))
rsprintf("<td><input type=text size=40 name=new_user_name value=\"%s\" readonly></td></tr>\n", str);
else
rsprintf("<td><input type=text size=40 name=new_user_name value=\"%s\"></td></tr>\n", str);
@@ -13334,6 +13342,7 @@
rsprintf("<tr><td class=\"menuframe\"><span class=\"menu1\">\n");
+ /* remove user-management buttons
if (is_admin_user(logbook, getparam("unm")) || !getcfg(logbook, "allow password change", str, sizeof(str))
|| atoi(str) == 1)
rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Change password"));
@@ -13345,7 +13354,7 @@
strlcpy(str, loc("Change config file"), sizeof(str));
rsprintf("<input type=submit name=cmd value=\"%s\">\n", str);
}
-
+ */
rsprintf("</span></td></tr></table>\n\n");
show_bottom_text(lbs);
rsprintf("</form></body></html>\r\n");
@@ -13579,9 +13588,9 @@
/*---- header ----*/
getcfg(lbs->name, "Authentication", str, sizeof(str));
- if (stristr(str, "Kerberos")) {
+ if (stristr(str, "Kerberos")|| stristr(str, "Webserver")) {
show_error
- ("This installation of ELOG uses site authentification\nwhere password recovery is not possible");
+ ("This installation of ELOG has outsourced its authentification\nwhere password recovery is not possible");
return;
}
@@ -13609,6 +13618,7 @@
void show_new_user_page(LOGBOOK * lbs, char *user)
{
+ char str[256];
/*---- header ----*/
show_html_header(lbs, TRUE, loc("ELOG new user"), TRUE, FALSE, NULL, FALSE);
@@ -13644,13 +13654,14 @@
rsprintf("<tr><td nowrap>Email:</td>\n");
rsprintf("<td colspan=2><input type=text size=40 name=new_user_email></tr>\n");
+ getcfg(lbs->name, "Authentication", str, sizeof(str));
+ if (!stristr(str, "Kerberos") && !stristr(str, "Webserver")) {
+ rsprintf("<tr><td nowrap>%s:</td>\n", loc("Password"));
+ rsprintf("<td colspan=2><input type=password size=40 name=newpwd>\n");
- rsprintf("<tr><td nowrap>%s:</td>\n", loc("Password"));
- rsprintf("<td colspan=2><input type=password size=40 name=newpwd>\n");
-
- rsprintf("<tr><td nowrap>%s:</td>\n", loc("Retype password"));
- rsprintf("<td colspan=2><input type=password size=40 name=newpwd2>\n");
-
+ rsprintf("<tr><td nowrap>%s:</td>\n", loc("Retype password"));
+ rsprintf("<td colspan=2><input type=password size=40 name=newpwd2>\n");
+ }
rsprintf("</td></tr></table>\n");
/*---- menu buttons ----*/
@@ -25391,7 +25402,12 @@
if (!enum_user_line(lbs, 0, str, sizeof(str))) {
if (isparam("new_user_name"))
return TRUE;
- show_new_user_page(lbs, NULL);
+ getcfg(lbs->name, "Authentication", str, sizeof(str));
+ if (stristr(str, "Webserver")) {
+ show_new_user_page(lbs, http_user);
+ } else {
+ show_new_user_page(lbs, NULL);
+ }
return FALSE;
}
@@ -25417,7 +25433,9 @@
}
}
- /* if invalid or no session ID, show login page */
+ /* if invalid or no session ID, show login page,
+ unless we have outsourced the authentication to webserver
+ */
if (!skip_sid_check && !sid_check(sid, user_name)) {
if (isparam("redir"))
strlcpy(str, getparam("redir"), sizeof(str));
@@ -26397,6 +26415,25 @@
if (lbs->n_attr < 0)
return;
+ /* if we outsource the authentication to Webserver and have no sid, just set a new sid */
+ getcfg(lbs->name, "Authentication", str, sizeof(str));
+ if (stristr(str, "Webserver")) {
+ if (http_user[0]) {
+ if (!sid_check(getparam("sid"), http_user)) { /* if we don't have a sid yet, set it */
+ /* get a new session ID */
+ sid_new(lbs, http_user, (char *) inet_ntoa(rem_addr), sid);
+ /* set SID cookie */
+ set_sid_cookie(lbs, sid);
+ }
+ } else {
+ sprintf(str, "Error: Misconfigured webserver, did not get X-Forwarded-User from it.");
+ show_error(str);
+ return;
+ }
+ }
+
+
+
/* check for new login */
if (isparam("uname") && isparam("upassword")) {
/* log logins */
@@ -27650,6 +27693,17 @@
*strchr(http_host, '\r') = 0;
}
+ /* extract X-Forwarded-User into http_user if Authentication==Webserver */
+ http_user[0] = 0;
+ if ((p = strstr(request, "X-Forwarded-User:")) != NULL) {
+ p += 17;
+ while (*p && *p == ' ')
+ p++;
+ strlcpy(http_user, p, sizeof(http_user));
+ if (strchr(http_user, '\r'))
+ *strchr(http_user, '\r') = 0;
+ }
+
/* extract "X-Forwarded-For:" */
if ((p = strstr(request, "X-Forwarded-For:")) != NULL) {
p += 16;
|
67179
|
Mon Jan 30 18:23:39 2012 |
| Yoshio Imai | $user_email | Question | Windows | 2.9.0 | Re: Return Code | It depends on how you actually call the elog client, but it outputs a message
Message successfully transmitted, ID=(new message id)
to the console upon successful transmission. Maybe you can catch this and evaluate? |
67181
|
Fri Feb 3 09:30:20 2012 |
| Christian Herzog | herzog@phys.ethz.ch | Question | Linux | 2.9.0 | Re: el cheapo LDAP binding | Hi Christof,
wow thanks, that's (almost) exactly what I was looking for! I only had to add
--- src/elogd.c.orig 2012-02-03 09:11:42.000000000 +0100
+++ src/elogd.c 2012-02-03 09:11:32.000000000 +0100
@@ -8375,6 +8375,10 @@
strcpy(list[i], "remote_host");
strlcpy(value[i++], rem_host, NAME_LENGTH);
+ /* add LDAP author */
+ strcpy(list[i], "http_user");
+ strlcpy(value[i++], http_user, NAME_LENGTH);
+
/* add local host */
strcpy(list[i], "host");
strlcpy(value[i++], host_name, NAME_LENGTH);
in order to get
Preset Author = $http_user
to work. I fully support getting your patches into upstream.
thanks a bunch,
-Christian
|
67183
|
Fri Feb 10 17:18:25 2012 |
| John Doroshenko | doroshenko@physics.rutgers.edu | Bug report | Linux | Windows | 2.9.0 | Re: ssl problems |
Olaf Kasten wrote: |
Hi there,
I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't connect to the elog server with ssl = 1 in elogd.cfg.
I tested with Firefox 3.6 and IE 7 installations and there are no problems.
I guess it's a bug. Does someone have a suggestion to solve that problem?
Thx. Olaf
|
Hi!
This just started happening here also. Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome. SAFARI works. Occurs in 2.8.0 and a newly built (even after
ssl yum updates) 2.9.0 version on SL5.5 system. Seems to accept self signed cert then nothing.. (connection reset message). Tried an stunnel from one port to port running elog
with SSL=0. Same behavior. Doesn't work on some browsers. Any clues?
Thanks,
-John |
67184
|
Sat Feb 11 05:43:33 2012 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug fix | Linux | Windows | 2.9.0 | Re: ssl problems |
John Doroshenko wrote: |
Olaf Kasten wrote: |
Hi there,
I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't connect to the elog server with ssl = 1 in elogd.cfg.
I tested with Firefox 3.6 and IE 7 installations and there are no problems.
I guess it's a bug. Does someone have a suggestion to solve that problem?
Thx. Olaf
|
Hi!
This just started happening here also. Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome. SAFARI works. Occurs in 2.8.0 and a newly built (even after
ssl yum updates) 2.9.0 version on SL5.5 system. Seems to accept self signed cert then nothing.. (connection reset message). Tried an stunnel from one port to port running elog
with SSL=0. Same behavior. Doesn't work on some browsers. Any clues?
Thanks,
-John
|
Hi everyone,
it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:
- Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
- Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.
I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.
To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.
I hope this settles the matter.
Cheers
Andreas
 ⇄
Detect language » English
PS: I've solved this with the help of google : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls |
67185
|
Sat Feb 11 05:47:27 2012 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Comment | Linux | 2.9.0 | Re: problems with https in Chrome and IE |
Christian Herzog wrote: |
Christian Herzog wrote: |
Andreas Luedeke wrote: |
Christian Herzog wrote: |
Andreas Luedeke wrote: |
Christian Herzog wrote: |
Andreas Luedeke wrote:
|
Christian Herzog wrote:
|
Andreas Luedeke wrote:
|
Christian Herzog wrote:
|
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...
|
[...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)
|
we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]
|
Sorry that I was mis-interpreting your question 
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
-
first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
-
second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
-
third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!
|
thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]
|
Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]
  ⇄
Detect language » English
|
[...]
And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.
thanks,
-Christian
|
Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.
I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.
 ⇄
Detect language » English
|
well maybe SL 5.7 is the explanation - it's old as the hills. Maybe newer versions of libssl or whatever make a difference? I might also try on a recent Fedora, let's see..
|
update: clean install on F16, plain vanilla, same problem: TCP connection broken
|
See https://midas.psi.ch/elogs/Forum/67184 to fix that problem. It is likely not a problem of ELOG, but of your firewall settings.
⇄
Detect language » English
|
67186
|
Sat Feb 11 22:05:36 2012 |
| Christian Herzog | herzog@phys.ethz.ch | Bug fix | Linux | Windows | 2.9.0 | Re: ssl problems |
Andreas Luedeke wrote: |
John Doroshenko wrote: |
Olaf Kasten wrote: |
Hi there,
I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't connect to the elog server with ssl = 1 in elogd.cfg.
I tested with Firefox 3.6 and IE 7 installations and there are no problems.
I guess it's a bug. Does someone have a suggestion to solve that problem?
Thx. Olaf
|
Hi!
This just started happening here also. Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome. SAFARI works. Occurs in 2.8.0 and a newly built (even after
ssl yum updates) 2.9.0 version on SL5.5 system. Seems to accept self signed cert then nothing.. (connection reset message). Tried an stunnel from one port to port running elog
with SSL=0. Same behavior. Doesn't work on some browsers. Any clues?
Thanks,
-John
|
Hi everyone,
it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:
- Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
- Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.
I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.
To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.
I hope this settles the matter.
Cheers
Andreas
 ⇄
Detect language » English
PS: I've solved this with the help of google : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls
|
Hi all,
it is NOT the firewall. First off, I don't use a firewall. 2. I AM our computing division. 3. if it were the firewall blocking the access, why do I see "TCP connection broken" in the elog log file? 4. it's not working on port 443 either.
Something's flaky in elog's https implementation. For me it's not a big deal any more, as I use an apache reverse proxy in production now anyway, but other people may not.
thanks,
-Christian |
67187
|
Sat Feb 11 22:07:37 2012 |
| Christian Herzog | herzog@phys.ethz.ch | Comment | Linux | 2.9.0 | Re: problems with https in Chrome and IE |
Andreas Luedeke wrote: |
Christian Herzog wrote: |
Christian Herzog wrote: |
Andreas Luedeke wrote: |
Christian Herzog wrote: |
Andreas Luedeke wrote: |
Christian Herzog wrote: |
Andreas Luedeke wrote:
|
Christian Herzog wrote:
|
Andreas Luedeke wrote:
|
Christian Herzog wrote:
|
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...
|
[...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)
|
we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]
|
Sorry that I was mis-interpreting your question 
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
-
first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
-
second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
-
third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!
|
thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]
|
Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]
  ⇄
Detect language » English
|
[...]
And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.
thanks,
-Christian
|
Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.
I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.
 ⇄
Detect language » English
|
well maybe SL 5.7 is the explanation - it's old as the hills. Maybe newer versions of libssl or whatever make a difference? I might also try on a recent Fedora, let's see..
|
update: clean install on F16, plain vanilla, same problem: TCP connection broken
|
See https://midas.psi.ch/elogs/Forum/67184 to fix that problem. It is likely not a problem of ELOG, but of your firewall settings.
⇄
Detect language » English
|
see #67184, I'm pretty positive it isn't.
-Christian |
|