Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 275 of 808  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Email Category OS ELOG Versiondown Subject
  68056   Wed Jul 22 22:54:59 2015 Entry Jaime Duranjduran@yorku.caBug reportLinux3.1.0-2elogd crashes with a URL

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.

  68064   Tue Aug 4 13:18:26 2015 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.0-2Re: elogd crashes with a URL

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.

 

  67959   Fri Jun 5 14:24:34 2015 Idea Stefan Rittstefan.ritt@psi.chInfoAll3.1.0+Different way CSS files are handled

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

  67960   Fri Jun 5 19:01:05 2015 Reply Andreas Luedekeandreas.luedeke@psi.chInfoAll3.1.0+Re: Different way CSS files are handled

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

 

  67968   Tue Jun 9 09:39:14 2015 Reply Stefan Rittstefan.ritt@psi.chInfoAll3.1.0+Re: Different way CSS files are handled

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

 

 

  67859   Sun Apr 12 21:12:29 2015 Question David PilgramDavid.Pilgram@epost.org.ukQuestionLinux3.1.0 c701Odd behaviour when attaching a file to an entry

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).

 

  67863   Thu Apr 23 15:13:06 2015 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.0 c701Re: Odd behaviour when attaching a file to an entry

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).

 

 

  67864   Thu Apr 23 15:37:37 2015 Reply David PilgramDavid.Pilgram@epost.org.ukQuestionLinux3.1.0 c701Re: Odd behaviour when attaching a file to an entry

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