Re: Reverse sort by Attribue, but it's only showing the last 6 entries by default., posted by Anthony on Mon Aug 10 09:01:24 2020
|
Thank you, Andreas! Not sure why I kept overlooking it in the manual. As for the number of entries when I sort, I'm not sure. I'll set it up to display a larger number and see what happens.
| Andreas Luedeke wrote: |
|
It is described in the manual at https://elog.psi.ch/elog/config.html#general
Entries per page = <number>
Funnily the default is "20". I have no idea why you see 6 entries.
| Anthony wrote: |
|
Hi,
I'm trying to use the Sort Attributes option to sort all entries by a user specified date. The issue I'm running into, is that although I can get it to work, it seems to only display the last 6 entries that I'm sorting by. If I click "All" to show all the entries, it's sorted perfectly. I'm using:
Sort Attributes = Due Date
Reverse sort = 0
Is there something I'm missing to get this working. Reading through the manual nothing jumped out at me.
|
|
|
Re: Reverse proxy setting of Elog for Apache httpd 2.4 so that changing password windows works ?, posted by Takashi Ichihara on Tue Mar 26 06:41:21 2019
|
The problem was resolved. I forgot to do this statement...
https://elog.psi.ch/elog/adminguide.html
Because elogd uses links to itself (for example in the email notification and the redirection after a submit), it has to know under which URL it is running. If you run it under a proxy, you have to add the line:
URL = http://your.proxy.host/subdir/
into elogd.cfg.
After inserting the URL in elogd.cfg, elog works correctly with Reverse Proxy Setting of Apache 2.4.
| Takashi Ichihara wrote: |
|
In CentOS 7.6 + Apache httpd-2.4.6 + ELOG V3.1.4 environment with Reverse Proxy setting of
/etc/httpd/conf/httpd.conf
:
ProxyRequests Off
RedirectMatch ^/elog$ /elog/
<Location /elog/>
ProxyPass http://mmm.riken.jp:3333/
ProxyPassReverse http://mmm.riken.jp:3333/
ProxyPassReverseCookiePath / /elog/
</Location>
:
It almost works fine. But Changing password has problem.
When clicking the "Forget password?" link in login window and displaying "Entering your user name or email address"
and entering it, an email is sent to the user:
----
This is an automatically generated account recovery email for host mmmm.riken.jp.
Please click on following link to recover your account:
http://mmm.riken.jp/elog/?redir=%3Fcmd%3DChange+password%26oldpwd%3DIHCPHXNTMJGEYDKY&uname=test&upassword=IHCPHXNTMJGEYDKY
ELOG Version 3.1.4
---
Clicking the URL above in the Firefox Browser results invalid URL:
http://mmm.riken.jp/?cmd=Change%20password&oldpwd=IHCPHXNTMJGEYDKY
These parameters does not pass to the elog by the Reverse Proxy setting above.
While accessing the URL of (native elog port: 3333)
http://mmm.riken.jp:3333/?cmd=Change%20password&oldpwd=IHCPHXNTMJGEYDKY
displays the normal page for Changing password windows for the user.
Is there any suggestions for the Reverse Proxy setting in Apache httpd 2.4
so that the changing password windows works fine ?
Thank you for any suggestions.
|
|
|
Re: Reverse proxy of Elog using Docker and Nginx?, posted by Stefan Ritt on Tue Aug 14 06:04:53 2018
|
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.
|
|
|
Re: Reverse proxy of Elog using Docker and Nginx?, posted by Andrew Wade on Fri Aug 17 22:07:41 2018
|
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.
|
|
|
|
Re: Reverse proxy of Elog using Docker and Nginx?, posted by Stefan Ritt on Mon Aug 20 12:42:24 2018
|
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.
|
|
|
|
|
Re: Reverse proxy of Elog using Docker and Nginx?, posted by Andrew Wade on Tue Aug 28 23:38:55 2018
|
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.
|
|
|
|
|
|
Re: Reverse proxy of Elog using Docker and Nginx?, posted by Bolko Beutner on Wed Sep 15 13:52:59 2021
|
I have the same problem -- did you find a solution in using the nginx revese proxy with user login?
| Andrew Wade wrote: |
|
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.
|
|
|
|
|
|
|
Re: Return Code, posted by Yoshio Imai on Mon Jan 30 18:23:39 2012
|
It depends on how you actually call the elog client, but it outputs a message
Message successfully transmitted, ID=(new message id)
to the console upon successful transmission. Maybe you can catch this and evaluate? |