Re: Bug Found, posted by nickc1 on Fri Jun 20 10:40:43 2003
|
> > Correct Way prior to 2.3.8
> >
> > http://192.168.0.1:99/Provisioning%20Request/35
> >
> > Broken way with new version
> >
> > http://192.168.0.1:99/Provisioning Request/35
>
> Exactly this problem has been fixed between 2.3.7 and 2.3.8, so can it be
> that you mixed up these two versions? To be precise, the fix happend in
> Revision 1.113 from 2003/06/04 08:17:35. So are you sure that you use a
> version of elogd after that modification? I tried to reproduce your
problem
> with the official 2.3.8 version, but I got the correct result.
Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this
upgrade, the only thing I kept was my own stylesheets and the config file.
One thing I just noticed is that if you dont have the URL statement set
under global properties, some machines quote the hostname of the machine at
which point this breaks the link. if you define the URL to the IP address
the problem goes away.
However even without the URL setting undefined, it works for some people
but not for others, I tried from 2 seperate machines and got 2 lots of
results, so I suspect it might be DNS related somewhere along the lines. |
|
Re: Bug Found, posted by Stefan Ritt on Mon Jun 23 10:53:55 2003
|
> Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this
> upgrade, the only thing I kept was my own stylesheets and the config file.
>
> One thing I just noticed is that if you dont have the URL statement set
> under global properties, some machines quote the hostname of the machine at
> which point this breaks the link. if you define the URL to the IP address
> the problem goes away.
>
> However even without the URL setting undefined, it works for some people
> but not for others, I tried from 2 seperate machines and got 2 lots of
> results, so I suspect it might be DNS related somewhere along the lines.
The only place I can see this problem could arise from is the "Referer:"
statement in the HTTP header. This is sent by the browser to elogd, so if the
included URL contains a blank, this could cause the problem in case no "URL"
statement is present in elogd.cfg. Can you please run "elogd -v" to see the
communication betwen elogd and your browser and check this? Maybe it depends
from the browser, or even from the history of previous accesses. If you
confirm that the "Referer:" statement contains blanks, I can put in a fix. |
|
Re: Bug, posted by Stefan Ritt on Thu Mar 1 22:19:22 2007
|
| Robert-Jan Schrijvers wrote: | when i was editting my Admin file, by mistake i typed the next line:
[a}Options Sessies = p-zis-pr1{1}, p-szh-pro{2}, p-dia-pro{3}, a-zis-ac1{1}, a-zis-ac2{2}, a-dia-acc{3}, ---------------------, Anders
{b} Options Sessies = FSC Pro{4}, FSC Acc{4}, Risc/Bus/Sms Pro{5}, Risc/Bus/Sms Acc{5}, ---------------------, Anders
{c} Options Sessies = BAO, BEH, BAOMPSO, BEHMPSO, Demonstrator, AFS, PTG, BSN, ---------------------, Anders
{d} Options Sessies = Wijziging, Storing
the next thing happened was that eLog created a new log which wasn't editable at all, the only thing i could do was deleting it (i created a monster...;-)
The first line/rule with the [ become the title, all other entries in the Admin file were used as a new Admin file. |
You shot yourself in the foot 
I agree that a clever syntax check on the config file would be nice, but it's very hard to imagine how many mistakes humans (including myself) can do, I would probably never catch all possible wrong cases. Giving my limited time, I will more work on new features and kindly ask you to be a bit careful in what you enter. I'm absolutely sure you will never make this mistake again  |
|
Re: Buffer Overflow?, posted by Stefan Ritt on Thu Jan 19 10:31:05 2006
|
| Chris Warner wrote: | Users can access root level directories by using a modified URL. I saw on some security web sites that this was a problem in previous versions. Was it not fixed in 2.6?
To recreate enter http://yourhost.yourdomain.com/../../../../etc/passwd
view your password file in the browser.
If this was previously reported, is there a fix?
Chris Warner |
Thanks for telling me, I didn't know. I was able to reproduce your problem under certain conditions, and I just released version 2.6.1 to fix it. However it has nothing to do with an old buffer overflow (see elog:941).
I would strongly advise everybody to upgrade as soon as possible. |
Re: Buffer Overflow?, posted by Chris Warner on Fri Jan 20 02:53:40 2006
|
| Stefan Ritt wrote: |
| Chris Warner wrote: | Users can access root level directories by using a modified URL. I saw on some security web sites that this was a problem in previous versions. Was it not fixed in 2.6?
To recreate enter http://yourhost.yourdomain.com/../../../../etc/passwd
view your password file in the browser.
If this was previously reported, is there a fix?
Chris Warner |
Thanks for telling me, I didn't know. I was able to reproduce your problem under certain conditions, and I just released version 2.6.1 to fix it. However it has nothing to do with an old buffer overflow (see elog:941).
I would strongly advise everybody to upgrade as soon as possible. |
Thanks for the quick response! |
|
Re: Bottom text = <file> not displayed in every screen?, posted by Stefan Ritt on Thu Jul 24 15:10:14 2003
|
> I tried to add a file with the "Bottom text = <file>" option.
>
> Although one would suggest that the bottom text file is included in every
> page, I only saw the file appear in the page that appears when you issue
> the "cmd=Edit" command.
That's really weired. The file is displayed at the bottom of single messages,
and the message list, but NOT at the form, which you reach with the "Edit"
command. So all I can suggest ist the following:
- Hit the reload button on your browser each time you change that file, to
make sure the browser does not display a page from its cache
- The HTML file is *included* in the normal page, so it should not contain
<HTML> or <BODY> tags. Start with a simple file containing something like
<center>Test</center>
and see what you get.
- Make sure the file is in the elog "resource" directory, which gets
displayed if you start elogd with the "-v" flag.
Let me know if any of this helped. |
|
Re: Boolean, posted by Stefan Ritt on Fri Aug 3 16:00:42 2007
|
| Grant Jeffcote wrote: | | I've noticed in the latest release when using the 'Find' page that any boolean expression (tick box) is now shown as '0,1 or unspecified'. Is this intentional? My colleagues are finding it hard to get their heads around what to choose and preferred the old 'Tick Box' option. Have there been changes to the configuration arguments used for Boolean that I've missed? |
Well, maybe you didn't realize, but searching for boolean attributes never really worked. If you want to search for entries where a boolean is true (or 1), then you could check the tick box in the past. But if you wanted to search for all entries were an attribute was false (not true) you could not do it, because the system assumed you are not interested in an attribute if the tick box was not checked. With the new way, you could either specify 'unspecified' meaning you are not filtering on this attribute, or you can explicitly specify '0', to look for entries where the attribute is false. The best would be to have a three-state tick box, which can be on/off/grayed. Under Windows API this does exist, but not in HTML. So I had to go with the three radio buttons.
Now one could argue how to name boolean states. There are several options:
- 0 / 1
- no / yes
- false / true
- off /on
I have chosen the first one, but that's kind of arbitrary. If the community believes that another one is better, I'm willing to change. |
|
Re: Boolean, posted by Grant Jeffcote on Fri Aug 3 17:03:46 2007
|
| Stefan Ritt wrote: |
| Grant Jeffcote wrote: | | I've noticed in the latest release when using the 'Find' page that any boolean expression (tick box) is now shown as '0,1 or unspecified'. Is this intentional? My colleagues are finding it hard to get their heads around what to choose and preferred the old 'Tick Box' option. Have there been changes to the configuration arguments used for Boolean that I've missed? |
Well, maybe you didn't realize, but searching for boolean attributes never really worked. If you want to search for entries where a boolean is true (or 1), then you could check the tick box in the past. But if you wanted to search for all entries were an attribute was false (not true) you could not do it, because the system assumed you are not interested in an attribute if the tick box was not checked. With the new way, you could either specify 'unspecified' meaning you are not filtering on this attribute, or you can explicitly specify '0', to look for entries where the attribute is false. The best would be to have a three-state tick box, which can be on/off/grayed. Under Windows API this does exist, but not in HTML. So I had to go with the three radio buttons.
Now one could argue how to name boolean states. There are several options:
- 0 / 1
- no / yes
- false / true
- off /on
I have chosen the first one, but that's kind of arbitrary. If the community believes that another one is better, I'm willing to change. |
Stefan
Thanks for the great explanation.
What are the chances of having a choice of the four options (as mentioned in your list) somehow so that when boolean-x is used (for example) in the configuration file the applicable option text is shown in the 'Find' page?
ie.
boolean-x = 0/1
boolean-y = no / yes
boolean-z = false / true
etc.
A long shot perhaps but don't know until you ask?
Thanks |
|