ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
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
|
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 |
67192
|
Mon Feb 13 18:36:29 2012 |
| Diego | diego.obradors@ciemat.es | Comment | Linux | 2.9.0 | Re: problems with https in Chrome and IE |
Christian Herzog wrote: |
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
|
Hi,
I have the same problem. with SSL = 1 in elog.cfg I am not able to connect using firefox 10 or chrome. However, using Internet explorer 6.0 it works fine.
Everything it has been checked in a local machine with windows 7 with and without firewall.
Use port 443, works fine with all browser.
Thank you so much!
Diego |
108
|
Thu Aug 15 18:00:36 2002 |
| Marcel Pils | marcel_pils@web.de | | | | Re: problems by defining the password file | in Unix:
i fixed the problem by defining a password file entry like 'user1::::'.
then i defined 'admin user = user1' in elogd.cfg.
then i connected with login name 'user1' and created new user (as admin).
in Windows2000:
if i do this steps and i save the new user, it fails. the server service
crash down.
> i work on Windows2000
>
> part of my elog.cfg:
>
> Passwort file = c:\elog\passwd.txt
> Self register = 1
> Guest user commands = config, admin, logout
>
> file system:
>
> - i created an emty file with name passwd.txt
>
> problem:
>
> - if i use the link "Register as new user" on login, it does not work.
> - if i login as guest user and choose the menu config, it only
> display the attributes Login_name, Full_name and Email.
> So i kann not create user.
>
> what should i do ?
> what are my mistakes ?
>
> Can you attache as sample password file ? |
436
|
Mon Sep 29 15:30:16 2003 |
| sridhar G | sridhar@thajes.com | | | | Re: problems by defining the password file | > i work on Windows2000
>
> part of my elog.cfg:
>
> Passwort file = c:\elog\passwd.txt
> Self register = 1
> Guest user commands = config, admin, logout
>
> file system:
>
> - i created an emty file with name passwd.txt
>
> problem:
>
> - if i use the link "Register as new user" on login, it does not work.
> - if i login as guest user and choose the menu config, it only
> display the attributes Login_name, Full_name and Email.
> So i kann not create user.
>
> what should i do ?
> what are my mistakes ?
>
> Can you attache as sample password file ?
Dear Friend!,
Only mistake in your file .cfg is spell mistake "Passwort" in "Passwort
file = c:\elog\passwd.txt" line. It should "Password file" t=d.
try some thing like below,
[Log]
Theme = default
Comment = Financial Accounting Bug posting
Attributes = Resource, Project Name, Task Desc, SDT, EEDT, ACDT, Percent WC,
Status
Options Type = Masters, Transactions, Reports
Options Category = Bug, New Feature, Client Requirement, Change
Required Attributes = Author, Type, Bug
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type
Password file =D:\Program Files\ELOG\logpwd.txt
;Self register = 0
Self register = 1
Admin user =sridhar
Menu commands = Back, Login, New, Edit, config, Delete, Reply, Find, Help,
Logout
Guest user commands = config, admin, Login, logout |
93
|
Wed Aug 7 15:51:18 2002 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | | | Re: problem with required attributes | > When an entry is submitted with an required attribute missing one gets to
> the resubmit page. When you the click your browsers back button all
> previously filled attribute field are blank.
>
> Is there a workaround to get the old text back?
>
> used versions:
> Elog 2.0.5
> Netscape 4.76
>
> Best regards,
>
> Stefan
This problem must be specific to NS 4.76, I don't have it on IE, NS 6, Mozilla
1, Opera etc. Maybe you should upgrade. Anybody else made this observation? |
1370
|
Thu Aug 4 20:32:56 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.9+r16 | Re: problem with list display attribute |
John Habermann wrote: | I not sure if this has been found and fixed as I did find something to do with the list display attribute in the forums but wasn't sure if it was the same thing.
There seems to be a bug with the List Display attribute in that it drops the last attribute of the list. So in my example if I want to display the Subject in my list I have to add a dummy attribute after it otherwise the Subject will not be displayed. The comma after Subject is not enough, but all you have to do is to add 1 letter and then you will see the subject in List view. If you don't all I see is the Date and Author fields and then the Text field in my Summary view in the log book.
List Display = Date,Author,Subject,t
I am running elog 2.5.9+r1674-1 on Debian sarge. |
I tried with the current 2.6.0-beta3 and it worked fine. Can you send me your full elogd.cfg in order to reproduce the problem? |
1380
|
Fri Aug 5 09:19:02 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | Linux | 2.5.9+r16 | Re: problem with list display attribute |
Stefan Ritt wrote: |
John Habermann wrote: | I not sure if this has been found and fixed as I did find something to do with the list display attribute in the forums but wasn't sure if it was the same thing.
There seems to be a bug with the List Display attribute in that it drops the last attribute of the list. So in my example if I want to display the Subject in my list I have to add a dummy attribute after it otherwise the Subject will not be displayed. The comma after Subject is not enough, but all you have to do is to add 1 letter and then you will see the subject in List view. If you don't all I see is the Date and Author fields and then the Text field in my Summary view in the log book.
List Display = Date,Author,Subject,t
I am running elog 2.5.9+r1674-1 on Debian sarge. |
I tried with the current 2.6.0-beta3 and it worked fine. Can you send me your full elogd.cfg in order to reproduce the problem? |
it is the pippo bug...
it was fixed in revision 1.675, just the next he was using...
it is discussed in elog:1170 |
|