I have just setup a new ELOG server on another machine. I took the latest source code from here: http://elog.psi.ch/elog/download/tar/elog-latest.tar.gz. Compiled it and ran. 
Still the same problem with Safari.

> I think this is a bug report. 
> However, I am not sure whether the problem is in the new version of Apple's WebKit (15.4) or in the ELOG itself.
> 
> When we edit an ELOG record with Safari (as of version 15.4, new WebKit features added) there are extra "newline" symbols (actually ^M) being added after EACH line of the record.
> 
> So, for instance, if I edit the following page:
> ```
> aaa
> aaa
> aaa
> ```
> 
> then after a "Submit" (without actually any changes) the record becomes:
> ```
> aaa
> 
> aaa
> 
> aaa
> ```
> 
> Our current ELOG version is "ELOG V3.1.4-4936b76".
> Could you please have a look? 

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

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. 

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

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

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

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.