Not Found

Re: Server dropping SSL connection while uploading large files

V3.1.3-aded4ae

Hi Erkcan,

I observed similar behaviours when attempting to do SSL uploads and mirroring over a WAN (see some of my recent posts). Having not received any responses/help, and no time to try debugging the source myself, I've changed the way I use ELOG such that my attachment uploads are always local (on my Mac laptop, where I do most of my ELOGging) and I have switched off the mirroring, choosing instead to do my own rsync backup to a central linux server on which I have running a read-only ELOG executable. This configuration is both relatively secure and stable, and it matches my use case well. More generally, however, it is unfortunate that this SSL and mirroring functionality isn't truly there for all users, even though the documentation touts it to be so.

Best regards,

Andreas W.

Erkcan Ozcan wrote:

Hi,

Could someone at least suggest how I could debug this problem myself? If I know where to start, perhaps I can fix it myself and contribute to the software.

Best,

Erkcan Ozcan wrote:

Hi,

I am having trouble with uploading large (>0.5MB) files to elog. We click on upload and in a couple of seconds, the webbrowser complains that the server has dropped the connection.

Following the suggestions I found on these forums (https://midas.psi.ch/elogs/Forum/66753), I increased the timeout.tv_sec to 30 in three locations in elogd.c, but this did not help.

The problem is present in my old elog installation (from ~2 years ago), as well as the latest git snapshot from bitbucket that I cloned on June 10, 2017.

PS: Upload seems to work for non-secure configuration. It still takes a while to load, but it completes. However we prefer to use secure connections ( SSL = 1 ).
PS: Using nmap I looked at the latency to the relevant port, it can be as high as 0.5sec, but most often it is shorter.

Cheers,
e.

68636

Thu Jun 29 08:36:03 2017

Re: Server dropping SSL connection while uploading large files

One possibility is to run elog in non-SSL mode and put an Apache server in front of it. The Apache server can then do the SSL communication, and forward all requests to elog in plain text (non-SSL). This has been proven to work with large attachments, actually that's the way I use it.

I didn't find time to debug the SSL problem. If anybody is interested in doing so, the relevant code is in function server_loop() around line 30015 (SSL_read()).

Stefan

Erkcan Ozcan wrote:

Hi,

Could someone at least suggest how I could debug this problem myself? If I know where to start, perhaps I can fix it myself and contribute to the software.

Best,

Erkcan Ozcan wrote:

Hi,

I am having trouble with uploading large (>0.5MB) files to elog. We click on upload and in a couple of seconds, the webbrowser complains that the server has dropped the connection.

Following the suggestions I found on these forums (https://midas.psi.ch/elogs/Forum/66753), I increased the timeout.tv_sec to 30 in three locations in elogd.c, but this did not help.

The problem is present in my old elog installation (from ~2 years ago), as well as the latest git snapshot from bitbucket that I cloned on June 10, 2017.

Cheers,
e.

68652

Fri Aug 18 01:02:41 2017

Travis Unkel

travisunkel@gmail.com

Re: Path disclosure on unfound file

3.1.3

I am having the same issue. If you go to midas.psi.ch/elogs/12345.htm you get the path disclosure issue.

Stefan Ritt wrote:

What URL did you use? If I try here on this forum I get:

which looks fine to me.

Bruce Bush wrote:

Greetings,

Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:

Not Found

The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server

ELOG version 3.1.0

Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?

Thank you,

68666

Mon Aug 21 11:22:09 2017

Problems with german_UTF8 language

Hi Stefan,

since recently (a few weeks) ELOG confuses the language translations.

Individual language strings are translated into garbage; most other strings are fine.

Currently I see the string "please select" translated into "ressed" (see attached picture), instead of what's written correctly in the language file "bitte auswählen".

But with every restart the corrupted strings vary: other strings are affected and other garbage strings are shown - some of them unreadable binary code (see Attachment 2).

I have the same version running in English: I see no problems there.

Kind regards

Andreas

Attachment 1: elog_lang_bug.png

Attachment 2: elog_lang_config_bug.png

68667

Mon Aug 21 11:45:06 2017

All

Bug with Drafts and Language German

Hi Stefan,

when one creates a new entry, and a draft entry exists for the logbook, then a menu appears (see attachment).

If one select "Neuen Eintrag anlegen" then it should ignore the draft and create a new entry.

This feat is done by adding a "&ignore=1" to the "new" command: "<URL>/?cmd=New&ignore=1".

The problem is, that it should not be "cmd=New&..." but "cmd=Neu", since the commands are part of the translation.

Due to this, no new entry can be created as long as a draft exists; at least not in any language other than english.

This problem apparently existed since the beginning of drafts, but it only created problems at our site recently.

Kind Regards

Andreas

PS: Here's a patch that works:

diff elogd.c elogd.c-orig
9575,9576c9575,9576
< rsprintf("<input type=button value=\"%s\" onClick=\"window.location.href='?cmd=%s&ignore=1';\">\n", loc("Create new entry"),
< loc("New"));
---
> rsprintf("<input type=button value=\"%s\" onClick=\"window.location.href='%s';\">\n", loc("Create new entry"),
> "?cmd=New&ignore=1");

Attachment 1: elog_lang_pending_draft_bug.png

68668

Mon Aug 21 12:16:05 2017

All

Re: Bug with Drafts and Language German

I've quickly checked: there are a couple more commands in the source code that are not language encoded. I guess some of them needs correction.

> egrep -n "cmd=[A-Za-z]" elogd.c
10293: rsprintf(" r.open('GET', '?jcmd=Unlock&edit_id=%d', true);\n", message_id);
11784: ("<label for=\"ELCode\"><a target=\"_blank\" href=\"?cmd=HelpELCode\">ELCode</a>  </label>\n");
13663: "\r\n%s URL : %s?cmd=Config&cfg_user=%s&unm=%s\r\n", loc("Logbook"),
14562: redirect(lbs, "?cmd=Config");
14625: sprintf(str, "../%s/?cmd=Config", getparam("lbname"));
14678: sprintf(str, "../%s/?cmd=Config", lbn);
15703: combine_url(lbs, host, "?cmd=GetMD5", url, sizeof(url), &ssl);
16378: strcat(str, "?cmd=GetConfig"); // request complete config file
16380: strcat(str, "?cmd=Download"); // request config section of logbook
16570: strcat(str, "?cmd=GetPwdFile"); // request password file
17575: rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17577: rsprintf("<br><b><a href=\"%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17579: rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
18959: if (strstr(ref, "cmd=Search&"))
18960: strlcpy(strstr(ref, "cmd=Search&"), strstr(ref, "cmd=Search&") + 11, sizeof(str));
26728: rsprintf("<a href=\"?cmd=Synchronize\">%s</a></td>\n", loc("Synchronize all logbooks"));

Andreas Luedeke wrote:

Hi Stefan,

when one creates a new entry, and a draft entry exists for the logbook, then a menu appears (see attachment).

If one select "Neuen Eintrag anlegen" then it should ignore the draft and create a new entry.

This feat is done by adding a "&ignore=1" to the "new" command: "<URL>/?cmd=New&ignore=1".

The problem is, that it should not be "cmd=New&..." but "cmd=Neu", since the commands are part of the translation.

Due to this, no new entry can be created as long as a draft exists; at least not in any language other than english.

This problem apparently existed since the beginning of drafts, but it only created problems at our site recently.

Kind Regards

Andreas

PS: Here's a patch that works:

68678

Wed Aug 23 15:11:32 2017

Re: Problems with german_UTF8 language

Just an update: I've re-compiled, reinstalled and restarted elogd for other reasons and now the corrupted strings are all gone. Everthing looks fine now.

But I never worry when a problem goes away before I could understand it: I'm confident that I will have plenty of time later, when the problem magically re-appears - likely I'll be called on a Friday night :-)

Andreas Luedeke wrote:

Hi Stefan,

since recently (a few weeks) ELOG confuses the language translations.

Individual language strings are translated into garbage; most other strings are fine.

Currently I see the string "please select" translated into "ressed" (see attached picture), instead of what's written correctly in the language file "bitte auswählen".

But with every restart the corrupted strings vary: other strings are affected and other garbage strings are shown - some of them unreadable binary code (see Attachment 2).

I have the same version running in English: I see no problems there.

Kind regards

Andreas

68698

Mon Nov 13 12:58:41 2017

Sara Vanini

vanini.sara@gmail.com