Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 275 of 808  Not logged in ELOG logo
icon1.gif   elogd crashes with a URL, posted by Jaime Duran on Wed Jul 22 22:54:59 2015 

URL causes elogd to crash when a global password file name doesn't match any group's password file name. 

The offending URL is copied from the address field of the browser after sorting a logbook by on of the fileds.

After login out and using the copied URL, elogd shows the authentication dialog and then crashes after the credentials are submited.

Some debugging point me to a NULL pointer on the following instruction in line   25502  of elogd.c :

  if (lbs->pwd_xml_tree) {

The work around was to name the global password file as the password file of one of the groups.

    icon2.gif   Re: elogd crashes with a URL, posted by Stefan Ritt on Tue Aug 4 13:18:26 2015 

I could not reproduce your problem. I can only fix it if I can reproduce it, so let's agree on a common test base. May I ask you to do the following:

  • Download the most recent elog version from bitbucket and compile it
  • Create two new logbooks "demo1" and "demo2" with minimal configuration, but using yor global password file which differs from the group ones
  • Send me step-by-step instructions how to trigger the problem, including your elogd.cfg file and your password files (of course with fake accounts)

If I can reproduce the crash, I can fix it.

Jaime Duran wrote:

URL causes elogd to crash when a global password file name doesn't match any group's password file name. 

The offending URL is copied from the address field of the browser after sorting a logbook by on of the fileds.

After login out and using the copied URL, elogd shows the authentication dialog and then crashes after the credentials are submited.

Some debugging point me to a NULL pointer on the following instruction in line   25502  of elogd.c :

  if (lbs->pwd_xml_tree) {

The work around was to name the global password file as the password file of one of the groups.

 

icon3.gif   Different way CSS files are handled, posted by Stefan Ritt on Fri Jun 5 14:24:34 2015 

Hi,

I just implemented a different way CSS files are handled in ELOG. Previously, we had the default.css, which could be adjusted for specific needs. Some people did that (like myself). So I changed a few colors etc. When I now implement a new feature in elog, it might need a new CSS class which I put in default.css. But this means that people who have modified this file get it either overwritten, or do not get the new styles.

In order to fix this, the default.css is now called elog.css and is always inluded in any ELOG page. If one specifies a CSS file with "CSS = <file.css>", then this CSS file is loaded in addition to elog.css. So one can put only the modifications into that file and inherits all the rest from elog.css. If new features come in elog.css, the installation with the personalized CSS file will then get the new features from the new elog.css automatically, and just overwrite a few settings in the personalized file. Here is an example:

elog.css:

td {
  color:black;
  font-size:12px;

}

Personalized file special.css, activated with "CSS = special.css" in the elogd.cfg file:

td {
  font-size:18px;
}

This personalized file now overwrites the font size from elog.css to 18 pixel, while maintaining all the rest from elogd.css.

The modification is committed to GIT and will be contained in the next release of elog.

/Stefan

    icon2.gif   Re: Different way CSS files are handled, posted by Andreas Luedeke on Fri Jun 5 19:01:05 2015 

Hi Stefan,

there is a little problem with the Makefile (on SL5 and SL6): the following line:

        @$(INSTALL) -m 0644 themes/default/* $(ELOGDIR)/themes/default/

/usr/bin/install: omitting directory `themes/default/icons'
make: *** [install] Error 1

When I go back to the old Makefile construct:

        @$(INSTALL) -m 0644 themes/default/icons/* $(ELOGDIR)/themes/default/icons/
        @for file in `find themes/default -type f` ;\
          do \
            if [ ! -f $(ELOGDIR)/themes/default/`basename $$file` ]; then  \
              $(INSTALL) -m 0644 $$file $(ELOGDIR)/themes/default/`basename $$file` ; \
           fi; \
          done

then it seems to work again.

Cheers

Andreas

Stefan Ritt wrote:

Hi,

I just implemented a different way CSS files are handled in ELOG. Previously, we had the default.css, which could be adjusted for specific needs. Some people did that (like myself). So I changed a few colors etc. When I now implement a new feature in elog, it might need a new CSS class which I put in default.css. But this means that people who have modified this file get it either overwritten, or do not get the new styles.

In order to fix this, the default.css is now called elog.css and is always inluded in any ELOG page. If one specifies a CSS file with "CSS = <file.css>", then this CSS file is loaded in addition to elog.css. So one can put only the modifications into that file and inherits all the rest from elog.css. If new features come in elog.css, the installation with the personalized CSS file will then get the new features from the new elog.css automatically, and just overwrite a few settings in the personalized file. Here is an example:

elog.css:

td {
  color:black;
  font-size:12px;

}

Personalized file special.css, activated with "CSS = special.css" in the elogd.cfg file:

td {
  font-size:18px;
}

This personalized file now overwrites the font size from elog.css to 18 pixel, while maintaining all the rest from elogd.css.

The modification is committed to GIT and will be contained in the next release of elog.

/Stefan

 

    icon2.gif   Re: Different way CSS files are handled, posted by Stefan Ritt on Tue Jun 9 09:39:14 2015 

Ok, fixed again.

Andreas Luedeke wrote:

Hi Stefan,

there is a little problem with the Makefile (on SL5 and SL6): the following line:

        @$(INSTALL) -m 0644 themes/default/* $(ELOGDIR)/themes/default/

/usr/bin/install: omitting directory `themes/default/icons'
make: *** [install] Error 1

When I go back to the old Makefile construct:

        @$(INSTALL) -m 0644 themes/default/icons/* $(ELOGDIR)/themes/default/icons/
        @for file in `find themes/default -type f` ;\
          do \
            if [ ! -f $(ELOGDIR)/themes/default/`basename $$file` ]; then  \
              $(INSTALL) -m 0644 $$file $(ELOGDIR)/themes/default/`basename $$file` ; \
           fi; \
          done

then it seems to work again.

Cheers

Andreas

Stefan Ritt wrote:

Hi,

I just implemented a different way CSS files are handled in ELOG. Previously, we had the default.css, which could be adjusted for specific needs. Some people did that (like myself). So I changed a few colors etc. When I now implement a new feature in elog, it might need a new CSS class which I put in default.css. But this means that people who have modified this file get it either overwritten, or do not get the new styles.

In order to fix this, the default.css is now called elog.css and is always inluded in any ELOG page. If one specifies a CSS file with "CSS = <file.css>", then this CSS file is loaded in addition to elog.css. So one can put only the modifications into that file and inherits all the rest from elog.css. If new features come in elog.css, the installation with the personalized CSS file will then get the new features from the new elog.css automatically, and just overwrite a few settings in the personalized file. Here is an example:

elog.css:

td {
  color:black;
  font-size:12px;

}

Personalized file special.css, activated with "CSS = special.css" in the elogd.cfg file:

td {
  font-size:18px;
}

This personalized file now overwrites the font size from elog.css to 18 pixel, while maintaining all the rest from elogd.css.

The modification is committed to GIT and will be contained in the next release of elog.

/Stefan

 

 

icon5.gif   Odd behaviour when attaching a file to an entry, posted by David Pilgram on Sun Apr 12 21:12:29 2015 

Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

 

The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc. 

I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).

 

    icon2.gif   Re: Odd behaviour when attaching a file to an entry, posted by Stefan Ritt on Thu Apr 23 15:13:06 2015 

This problem has been fixed in Version 3.1.0-2. Please upgrade.

David Pilgram wrote:

Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

 

The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc. 

I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).

 

 

    icon2.gif   Re: Odd behaviour when attaching a file to an entry, posted by David Pilgram on Thu Apr 23 15:37:37 2015 

Thanks Stefan, that did the trick.

Had a bit of an effort with the git repository, though, kept getting 403 errors when tried the

git clone https://bitbucket.org/ritt/elog as per the "download" page.

error: The requested URL returned error: 403 while accessing https://bitbucket.org/ritt/elog/info/refs

Stefan Ritt wrote:

This problem has been fixed in Version 3.1.0-2. Please upgrade.

David Pilgram wrote:

Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

 

The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc. 

I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).

 

 

 

ELOG V3.1.5-3fb85fa6