Organizr: Add HTTP Proxy Support

[jeremyscalpello]

It would be great if Organizr supported the ability to proxy instead of loading the URLs in an iframe.

It could proxy the requests through Organizr and only do so when you're logged in. This would allow us to make the dashboard public-facing without needing to open all the apps to the internet, as well as not have to depend on the (possibly poor) authentication the app provides.

[causefx]

This was suggested earlier but I didn't have any success on implementation. it would have to be a php script that works flawless :/

[phairplay]

This would be amazing
As currently I have http auth set up on all my tabs... /sonarr etc
Currently I have Idashboard (also with http auth) and guest enabled for all tabs meaning I only need to enter my user and password once for them all.

[rvdwegen]

+1 on this one. I would love to get rid of htaccess

[causefx]

i've been playing around with a few php proxies and they all suck :/

[riccla0321]

+1 on this. It would be awesome to use Organizr over a secure proxy with SSL.

[2wheelsdown]

Like this? https://drive.google.com/file/d/0BzPd75yQAJYhWG1keDJpWU9QZVU/view?usp=sharing

[causefx]

@2wheelsdown that is another webserver, wont help us here :(

[ImperialXT]

I've found a work around of sorts for this. It'll only work for certain setups like mine.

My setup:

to access my organizr install you go to mydomain.com and to access plexypy you'd go to mydomain.com/plexpy

I use nginx and with location and proxy_pass statements

 location /plexpy {
    add_header X-Frame-Options "SAMEORIGIN";
    proxy_pass http://127.0.0.1:8181;
 }

y for this example let's assume it's exposed to the web to anyone

However if I modify the login sections of user.php to set another cookie like below:

setcookie("OrganizrRand", "test", time() + (86400 * 7), "/");

and then I check for this cookie in nginx at the location block

 location /plexpy {
    if ($cookie_OrganizrRand != "test") { return 403; }
    add_header X-Frame-Options "SAMEORIGIN";
    proxy_pass http://127.0.0.1:8181;
 }

this is now returning 403 to anyone who hasn't successfully logged into my organizr installation.

This should totally be doable in apache also, I'd just have to fiddle a bit to suggest the relevant config options.

[phairplay]

@ImperialXT
do you still have http auth set up for each sub site?

[causefx]

@ImperialXT that is actually really good. you weren't able to use the cookie that Organizr already sets?

[ImperialXT]

@causefx no because I'm checking the content of that cookie and nginx needs to know what content to look for. It's not just a simple is the cookie set check

[ImperialXT]

@phairplay no because the cookie check is enough for me

[causefx]

@ImperialXT I just added this into the code, you will set a cookie password in the settings and edit your nginx configuration to:

 location /plexpy {
    if ($cookie_cookiePassword != "PASSWORDHERE") { return 403; }
    add_header X-Frame-Options "SAMEORIGIN";
    proxy_pass http://127.0.0.1:8181;
 }

at least now it will survive upgrades for you. I will push a new update tomorrow.

[ImperialXT]

@causefx excellent thanks for that

[causefx]

@ImperialXT nah man thank you, that was an excellent idea.

[causefx]

@ImperialXT update is live

[ImperialXT]

@causefx thanks. I'll pull it down. I've also submitted a pull request to fix up the .gitignore file :)

[causefx]

nice, thank you, just merged it into develop.

[causefx]

does anyone use Apache? would love to test this new version with that so we can add it to the wiki

[ImperialXT]

You would need something like in a location block in the vhost iirc
RewriteEngine On
RewriteCond %{HTTP_COOKIE} !cookie_name=specific_value [NC]
RewriteRule ^ https://mydomain.com [NC,L,R=302]

[causefx]

nice, just need someone to test it :)

[evulhotdog]

In nginx, this doesn't work for any location that needs a rewrite to function properly. Is there any solution for this?

[ImperialXT]

@evulhotdog are you able to give me an example of what you're talking about? I can probably figure something out.

[evulhotdog]

@ImperialXT So this works, for forwarding, but I can access it, even if the cookie is not set and the referrer isn't 10.0.0.10.

     location /monit/ {
            rewrite /monit/(.*) /$1 break;
            proxy_pass   http://10.0.0.10:8083;
            valid_referers 10.0.0.10 ~.;
            if ($invalid_referer) { return 401; }
            if ($cookie_cookiePassword != "the_pw") { return 403; }
    }

[causefx]

Proxy pass has to be at the end of everything

Sent from my iPhone

On Mar 11, 2017, at 9:38 PM, evulhotdog [e-mail] wrote:

So this works, for forwarding, but I can access it, even if the cookie is not set and the referrer isn't 10.0.0.10.

 location /monit/ {
        rewrite /monit/(.*) /$1 break;
        proxy_pass   http://10.0.0.10:8083;
        valid_referers 10.0.0.10 ~.;
        if ($invalid_referer) { return 401; }
        if ($cookie_cookiePassword != "the_pw") { return 403; }
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[evulhotdog]

@causefx even after moving it to the bottom of the block, there's no difference. I've moved a few things around before thinking that maybe it had some order of operations, but I don't think it does.

[ImperialXT]

@evulhotdog
try this

  location /monit/ {
            if ($cookie_cookiePassword != "the_pw") { return 403; }
            rewrite /monit/(.*) /$1 break;
            valid_referers 10.0.0.10 ~.;
            if ($invalid_referer) { return 401; }
            proxy_pass   http://10.0.0.10:8083;
    }

I'm not quite sure what you're expecting to accomplish with the valid_referers part.

[evulhotdog]

That seems to work w/ the cookie, but the $invalid_referer does not. Any idea why?

[ImperialXT]

That seems to work w/ the cookie, but the $invalid_referer does not. Any idea why?

Not sure to be honest, as I'm not quite sure what you're trying to achieve with it.

What's the purpose of the $invalid_referer check?

[evulhotdog]

It only allows you to refer from 10.0.0.10. This is just another check to prevent accessing https://site.com/sonarr/ directly and to force all traffic through the root and use that authentication. Essentially ensuring that only that IP can talk to... that IP, for those locations.

Works for every single location, just not the ones with a rewrite in them (from what I can tell.)

[ImperialXT]

seems a bit pointless with the cookie check also in place. But try putting it before the rewrite.

[kendokan]

Have a look at https://github.com/causefx/Organizr/issues/141. Auth_request is a better solution to protect URLs for nginx users. No static shared secret, everything happens on the server side, and the nginx configuration is cleaner.

Edit: Also note this could be pretty easily expanded to auth not only simple logged in/logged out status, but also whether the logged in Organizr user has access to that specific location block in nginx. It's really flexible since the script tells nginx whether or not to permit access to the URL.

[causefx]

Will dive into this in the future. for now we have #141