| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69594
|
Tue Dec 27 12:44:52 2022 |
 | Andrey | kowaraj4stuff@gmail.com | Info | All | ELOG V3.1.4-493 | Duplicated \n in "plain" format with new WebKit |
Dear Stefan,
There is a problem with editing an Elog page in "plain" format with the following "User Agent" :
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15"
It duplicates the newline symbols such that "1<CRLF>2" becomes "1<CRLF><CRLF>2". If edited again - "1<CRLF><CRLF><CRLF><CRLF>2".
I blame the new version of the Apple WebKit.
It works fine with Chrome (user agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"). But fails with Safari.
Could you please have a look?
Thank you in advance,
Andrey Pashnin
AMS collaboration
|
|
69595
|
Wed Dec 28 16:09:30 2022 |
 | Andrey | kowaraj4stuff@gmail.com | Info | All | ELOG V3.1.4-493 | bug report to webkit.org |
It shound't be a "bug report", sorry. I have changed the category to "Info".
It seems to be really a bug in the WebKit core. I have created a bug report there. For reference: https://bugs.webkit.org/show_bug.cgi?id=249923
I am going to try to patch the ELOG code to handle the content of the textarea in the "plain" format.... it doesn't seem possible though. |
|
69596
|
Thu Dec 29 20:26:11 2022 |
| Andrey | kowaraj4stuff@gmail.com | Bug fix | All | ELOG V3.1.4-493 | a hack around |
FYI.
Removing "wrap=hard" on the line #11461 in the elogd.cxx file resolves my problem.
- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);*/
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
|
|
68832
|
Mon Aug 13 21:09:30 2018 |
 | Andrew Wade | awade@caltech.edu | Question | Linux | Other | 3.1.2 | Reverse proxy of Elog using Docker and Nginx? |
I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world. The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.
It worked great in the initial test. However, I have an issue with authentication. When I password protect the elog it goes to a login page. When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning). So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication. I am never able to actually get to the protected content.
Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?
Side note: I have tried using Apache to do the same and authentication worked fine. But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router. There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt. |
|
68835
|
Fri Aug 17 22:07:41 2018 |
| Andrew Wade | awade@caltech.edu | Question | Linux | Other | 3.1.2 | Re: Reverse proxy of Elog using Docker and Nginx? |
Yes, I tried setting the URL parameter to the url used by the proxy. It goes to the correct address but that landing is the login page.
Andrew
| Stefan Ritt wrote: |
|
Have you tried the "URL = ..." statement? This determines you elog redirects if you log in. If you reach elog through a proxy, the URL is a different one that if you access it directly. In your case the proxy URL might be necessary.
Stefan
| Andrew Wade wrote: |
|
I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world. The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.
It worked great in the initial test. However, I have an issue with authentication. When I password protect the elog it goes to a login page. When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning). So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication. I am never able to actually get to the protected content.
Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?
Side note: I have tried using Apache to do the same and authentication worked fine. But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router. There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt.
|
|
|
|
68838
|
Tue Aug 28 23:38:55 2018 |
| Andrew Wade | awade@caltech.edu | Question | Linux | Other | 3.1.2 | Re: Reverse proxy of Elog using Docker and Nginx? |
It does indeed seem to be a cookie stripping issue. I just need to figure out how to get Nginx to forward these properly.
Thanks for the help.
| Stefan Ritt wrote: |
|
Actually this forum works through an Apache reverse proxy with authentication and it works, so I suspect that the problem has to do with jwilder/nginx-proxy. Since we don't have this here, all I can propose is that you do debugging yourself. Run elogd with the -v flag so that you see all requests coming from the user through the proxy. Compare the requests through Apache and Nginx to see if any argumets are stripped or mangled. Upon successful login, elog sets a cookie with a unique session-ID (the cookie name is "sid") to the browser. If you proxy strips that cookie, you would land on the login page. Maybe look in that direction.
Stefan
| Andrew Wade wrote: |
|
Yes, I tried setting the URL parameter to the url used by the proxy. It goes to the correct address but that landing is the login page.
Andrew
| Stefan Ritt wrote: |
|
Have you tried the "URL = ..." statement? This determines you elog redirects if you log in. If you reach elog through a proxy, the URL is a different one that if you access it directly. In your case the proxy URL might be necessary.
Stefan
| Andrew Wade wrote: |
|
I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world. The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.
It worked great in the initial test. However, I have an issue with authentication. When I password protect the elog it goes to a login page. When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning). So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication. I am never able to actually get to the protected content.
Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?
Side note: I have tried using Apache to do the same and authentication worked fine. But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router. There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt.
|
|
|
|
|
|
68582
|
Sat Mar 18 02:10:33 2017 |
| Andrew Daviel | advax@triumf.ca | Question | Linux | 2.7.5 | Issue with zero-length mail attachments |
We have elog-2.7.5-1.i386 on SL 5
If I create an elog entry using the web interface, and include an inline image, email is sent with a zero-length named attachment - the MIME header is present, but no content.
In the config file, Email Format = 47, though I also tried with format = 63.
Is this a bug that was fixed in a later version, or a configuration error (or a new bug) ?
|
|
68583
|
Mon Mar 20 22:44:27 2017 |
| Andrew Daviel | advax@triumf.ca | Question | Linux | 2.7.5 | Re: Issue with zero-length mail attachments |
| Andrew Daviel wrote: |
|
We have elog-2.7.5-1.i386 on SL 5
If I create an elog entry using the web interface, and include an inline image, email is sent with a zero-length named attachment - the MIME header is present, but no content.
In the config file, Email Format = 47, though I also tried with format = 63.
Is this a bug that was fixed in a later version, or a configuration error (or a new bug) ?
|
Probably us not having ImageMagick installed. elog was able to attach pdf's, xpm's and xbm's to email, but not jpeg's or png's, though they inlined OK in HTML on the server.
It seems OK, I think, after installing ImageMagick and restarting. |