Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#1194 closed patch (Fixed)

Infinite login prompt in web ui through reverse proxy

Reported by: non7top Owned by:
Priority: trivial Milestone: 1.3.2
Component: Web UI Version: 1.3.1
Keywords: file upload FileWindow.js Cc: desired.mta@…, saad.dupuy@…

Description

When I use web ui through nginx as reverse proxy, authentification never completes and keep showing the box with Login field. Also firefox gets hung on the page and consume 100% cpu. This doesn't hapen when connecting to web ui dirctly.

I'm using following nginx config:

location /deluge {

proxy_pass http://s:8112/; proxy_redirect off;

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-Deluge-Base /deluge/;

commit e7c7b8f4db4acaa5811c2573180a0afd6d24f947

Attachments (1)

deluge.diff (1.1 KB) - added by Motiejus 13 years ago.
auth.py cookie base path vs deluge-web 1.3.1

Download all attachments as: .zip

Change History (15)

comment:1 Changed 14 years ago by damoxc

  • Resolution set to invalid
  • Status changed from new to closed

This is an issue with your proxy setup. I haven't set up nginx before but in Apache you need to configure Cookie passing.

comment:2 Changed 13 years ago by Motiejus

  • Cc desired.mta@… added
  • Component changed from other to webui
  • Milestone changed from 1.4.0 to 1.3.x
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Type changed from defect to patch
  • Version changed from 1.2.0_dev to 1.3.0_dev

I needed reverse proxy with nginx as well, did not work for the same reason, and I had a deeper look. The problem was that deluge was not rewriting it's cookie paths correctly: _session_id=88ee05d3d56c35ba54a4dc64b7fd80cf2390; Expires=Fri, 04 Feb 2011 03:31:15 GMT; Path=/json

Should be: _session_id=88ee05d3d56c35ba54a4dc64b7fd80cf2390; Expires=Fri, 04 Feb 2011 03:31:15 GMT; Path=/deluge/json

There is a four-line patch to auth.py. It worked with nginx config as above, --base='/deluge/'.

Changed 13 years ago by Motiejus

auth.py cookie base path vs deluge-web 1.3.1

comment:3 Changed 13 years ago by Motiejus

Actual nginx configuration that worked for me:

    location /deluge/ {
        proxy_pass  http://127.0.0.1:8112/;
        proxy_redirect  off;
        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_pass_header Set-Cookie;
        proxy_pass_header P3P;
    }   

Note that with proxy_pass_header Set-Cookie; set it doesn't work without the patch for the same reason mentioned.

comment:4 Changed 13 years ago by damoxc

Thanks for this, I just assumed it was a web-server misconfiguration since it worked in apache, and I don't really use a reverse proxy so haven't had much time to investigate why it was happening.

I'll try and get around to applying this at some point today.

comment:5 Changed 13 years ago by damoxc

  • Resolution set to fixed
  • Status changed from reopened to closed

Applied in master rb0a0574ae0 and 1.3-stable r26410ca9c1

comment:6 Changed 13 years ago by Motiejus

Good, thanks. One question. Will this line:

component.get("Web").get_config()["base"])

work with X-Deluge-Base header?

comment:7 Changed 13 years ago by Motiejus

Tried. Did not work. FYI, My patch makes authentication work only for config entry:

$XDG_CONFIG_HOME/deluge/web.conf:
...
"base" : "/deluge/",
...

comment:8 Changed 13 years ago by damoxc

No that wouldn't work, the base can be switched dynamically per-request so I don't modify the config value.

I wonder if request.path is simple enough? Would you mind testing as I don't have a nginx reverse proxy set up at the moment.

comment:9 Changed 13 years ago by Motiejus

Hum, I am not sure if request has it's real request path in reverse proxy configuration. Client request:

http://server/deluge/ in reverse proxy (apache as well) becomes to http://127.0.0.1:8112/ consequently request.path is "/", am I right? This is why you needed base parameter, since server sitting behind proxy does not know anything about real path.

I will gladly test any configurations.

comment:10 Changed 13 years ago by damoxc

Very true, sorry I have only just woken up :-)

In that case I would suggest a get_base(request): ... function in common.py and that could then be shared between auth and server. That sounds the best to me.

comment:11 Changed 13 years ago by j2cx

  • Cc saad.dupuy@… added
  • Keywords file upload FileWindow.js added
  • Priority changed from major to trivial
  • Version changed from 1.3.0_dev to 1.3.1

Hi. First, thanks for the patch! (and sorry in advance for my approximative english).

Using 1.3.1 with nginx proxy, I saw with this patch has as a side effect to get the file upload progress bar blocked into a loop while uploading a local file.

This is because the base's value isn't added to the FileWindow?.js or deluge-all.js, with ngingx denying the access to /upload. The loop seems to be just a ui behavavior.

Got it to work adding deluge.config.base to the upload url in deluge-all.js, line 352.

As I didn't saw this modification appearing in the sources from git repo, this places seems to be the better to report it ;-)

comment:12 Changed 13 years ago by Cas

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:13 Changed 13 years ago by damoxc

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:14 Changed 13 years ago by Cas

  • Milestone changed from 1.3.x to 1.3.2
Note: See TracTickets for help on using tickets.