> I noticed that when I put in a password such as <test1> a person can login 
> with the password <test2> or any other number at the end.  Is the 
> encryption not able to tell the difference between numbers?  The encrypted 
> passwords even look the same in the password file.  Is this a bug?

This is really strange. Encryption only works on ASCII characters and does 
not distinguish between letters and digits. When I try to reporoduce that, 
the system distinguishes well between "test1" and "test2". The first gives 
encrypted "dGVzdDE=" and the second gives "dGVzdDI=", note the different "E" 
and "I". So I have no clue right now what is wrong in your installation. If 
running under Linux, you can compile elogd after adding "-DHAVE_CRYPT" and "-
lcrypt" to the Makefile to use the standard Linux crypt() function, but I 
would rather like to understand what is wrong in your case.

- Stefan

> > I noticed that when I put in a password such as <test1> a person can 
login 
> > with the password <test2> or any other number at the end.  Is the 
> > encryption not able to tell the difference between numbers?  The 
encrypted 
> > passwords even look the same in the password file.  Is this a bug?
> 
> This is really strange. Encryption only works on ASCII characters and does 
> not distinguish between letters and digits. When I try to reporoduce that, 
> the system distinguishes well between "test1" and "test2". The first gives 
> encrypted "dGVzdDE=" and the second gives "dGVzdDI=", note the 
different "E" 
> and "I". So I have no clue right now what is wrong in your installation. If 
> running under Linux, you can compile elogd after adding "-DHAVE_CRYPT" 
and "-
> lcrypt" to the Makefile to use the standard Linux crypt() function, but I 
> would rather like to understand what is wrong in your case.
> 
> - Stefan

Ok, try it with the passwords <hello1> and <hello2>.  Then when you go to log 
in, put in the password of <hello> with any single number after it and let me 
know if the problem shows up for you because that is the password I was 
using.  When I look at it encrypted in the passwd file they look the same.  I 
also installed the latest version today which is newer than the one I was 
using before and it still does it.  I appreciate your time.

Byron

> Ok, try it with the passwords <hello1> and <hello2>.  Then when you go to 
log 
> in, put in the password of <hello> with any single number after it and let 
me 
> know if the problem shows up for you because that is the password I was 
> using.  When I look at it encrypted in the passwd file they look the 
same.  I 
> also installed the latest version today which is newer than the one I was 
> using before and it still does it.  I appreciate your time.

Ok, I finally found the problem: Whenever a password has a length which can 
be divided by three (like 6 or 9), the last two characters are completely 
ignored. This problem will be fixed in version 2.3.5. Is has to be noted 
that all existing passwords with the mentioned length have to be re-entered 
after the upgrade from 2.3.4 to 2.3.5. Since one cannot log in with the old 
password on those cases, a "Forgot password?" links has been added to the 
login screen, which can be used to create a new password and send it to the 
registered email address.

I am using 2.3.4 and I am still having this problem.  If someone posts a
message with an attachment, and I then reply to that message, the attachment
gets 'deattached' from that message.  However, the file is still in the
logbook directory, so it is possible to recover it, but it did cause a slight
panic the first time it happened :)

I see there is a 2.3.5 version now, but the changelog doesn't say anything
about this problem, so I have not tried it yet.

Is there a 'trick' to fix this problem?

EDIT: I noticed when I replyed to your message, your elog.cfg attachment is
no longer there.  So it appears it's not fixed in 2.3.5 either..


> This is a known problem and has been fixed in version 2.3.4, which has been 
> released today. To prove that it's working, I attached the current 
> elogd.cfg from this forum.

> I am using 2.3.4 and I am still having this problem.  If someone posts a
> message with an attachment, and I then reply to that message, the attachment
> gets 'deattached' from that message.  However, the file is still in the
> logbook directory, so it is possible to recover it, but it did cause a 
slight
> panic the first time it happened :)

Uups, that is indeed a problem. I found that it was unrelated to the first 
one, so it was there since quite some time now. I fixed it. It will come out 
in 2.3.6 or can be obtained already now from CVS. It is trongly recommended 
to upgrade all installations to avoid this problem.

> > I am using 2.3.4 and I am still having this problem.  If someone posts a
> > message with an attachment, and I then reply to that message, the 
attachment
> > gets 'deattached' from that message.  However, the file is still in the
> > logbook directory, so it is possible to recover it, but it did cause a 
> slight
> > panic the first time it happened :)
> 
> Uups, that is indeed a problem. I found that it was unrelated to the first 
> one, so it was there since quite some time now. I fixed it. It will come 
out 
> in 2.3.6 or can be obtained already now from CVS. It is trongly recommended 
> to upgrade all installations to avoid this problem.

Just as a test, I reply to my previous message... looks like it works.

EDIT: I downloaded the latest elogd.c from CVS, replaced the one from the
latest tar, and recompiled.  Worked great!

Thanks for the prompt response, Stefan!

> > I am using 2.3.4 and I am still having this problem.  If someone posts a
> > message with an attachment, and I then reply to that message, the attachment
> > gets 'deattached' from that message.  However, the file is still in the
> > logbook directory, so it is possible to recover it, but it did cause a 
> slight
> > panic the first time it happened :)
> 
> Uups, that is indeed a problem. I found that it was unrelated to the first 
> one, so it was there since quite some time now. I fixed it. It will come out 
> in 2.3.6 or can be obtained already now from CVS. It is trongly recommended 
> to upgrade all installations to avoid this problem.

I repeat ...
. Opera browser 7.03 simply crashes, when choosing the direct URL to our 
logbook, i.e. http://localhost:8080/logbook2. We have set a general 
password file and a different read password for each of our logbooks.
If we choose http://localhost:8080/logbook1 everything is fine. We get a 
window "Authentication required" and type in simply the read password, no 
user name.
If we choose http://localhost:8080/logbook2 the behaviour is different. We 
see the window "Authentication required" appear, then Opera crashes.
Change of the read passwords did not change this erroneous behaviour. This 
problem was not with version ELOG 2.3.4.

In Internet Explorer 6 all is okay.


 ... and add

The behaviour is different in those browsers even with the start page at 
http://localhost:8080/
Internet Explorer 6 demands a login. But as we have no password we cannot 
login.
Opera 7.03 demands no login and simply offers the list of logbooks to 
choose one.