I am spending now over two days on that issue, trying several servers (apache, now nginx), searching the whole web, but had no luck so far.

First: sorry for posting my urls with http-s instead of https - this is because I am not allowed to post more than two links here :(

  1. A website offers access to a magazine archive when you buy an login account. We now have one account for our whole institute. But we don't want to share the login credentials among all people here, so we thought we might set up a proxy who "does the login in background" or something.

  2. The login credentials can be submitted via http GET (query paramerters in the URL) like


  3. Everything surrenders ssl encryption.

  4. The setup:

    [user] --> http-s://proxyserver.org/science/issueSelect --> [proxy] --> http-s://www.magazine.org/science/issueSelect?user=institute&pass=secret [magazine-server]
    [magazine-server] --> http-s://www.magazine.org/science/issueSelect?ser=institute&pass=secret --> [proxy] --> http-s://www.proxyserver.org/science/issueSelect --> [user]

This should normally be no problem to configure with nginx, apache etc. but I have the problem, that sometimes the login credentials appear in the users browser url bar. When does this happen? When the magazine-server delivers "special" hyperlinks (which are probably also redirected to somewhere else). Those hyperlinks appear not to be relative, they are absolute. Nevertheless, the reverse proxy seem to translate them back correctly, because also those links have my proxyhost.org as fqdn.

Some navigation links --> working the way they should
a href="/nature/...">Nature
a href="/science/...">Science
a href="/it/...">IT

Some article overview links --> on Click revealing login credentials in url bar
a href="http-s://proxyserver.org/science/2015/1>Issue 2015 / 1
a href="http-s://proxyserver.org/science/2015/2>Issue 2015 / 2

I have also got the feeling that there are also some redirects behind those issue links.

Here is my configuration:

server {
    listen 443 ssl;
    server_name proxyserver.org;

    ssl_certificate           /etc/nginx/ssl/proxyserver.certificate;
    ssl_certificate_key       /etc/nginx/ssl/proxyserver.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/access.log;

    location / 
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;
      set $args $args&user=institute&pass=secret;
# working as well
#      rewrite ^(.*)$ $1?user=institute&pass=secret? break; 
      proxy_pass      https://www.magazine.org;
# not working: 404
#     proxy_redirect  https://www.magazine.org/ https://proxyserver.org/; 

Any ideas how to solve this? Or do I need a lillte more elaborated approach, something like a little client on my proxy who also keeps the session cookies etc? Thank you!

  • 1
    You are wrong. We have obtained a full licence for our institute and the magazine provider leaves it to us how we implement the access to their archive. The provider is even informed about our proxy approach. Please save your "you are hacking around evil it" comments...
    – Ranunculum
    Aug 27, 2015 at 15:05

1 Answer 1


Okay, it was the location header which was modified, causing the url query parameters being displayed in the url bar. I could get rid of this phenomenon by modifying this on the fly by the nginx engine:

proxy_redirect "~^(.*)\?.*$" "$1";

I was not aware that proxy_redirect is regex capable, should have read the manual more detailled. Now I have got functionality as expected.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .