<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I managed to get this working, both having a Docker containerized
Girder be self-aware of its own proxying (edits to
girder.local.cfg) and for Oauth to work over the various reverse
proxy hops.</p>
<p>Within the girder container, I edit the girder.local.config file
to add lines controlling its self-awareness about proxying.</p>
<ul>
<li>[global]</li>
<ul>
<li>tools.proxy.on: True</li>
<li>tools.proxy.base: <a class="moz-txt-link-rfc2396E" href="https://outward.facing.edu/girderdev">"https://outward.facing.edu/girderdev"</a></li>
<li>tools.proxy.local: ""</li>
</ul>
<li>[server]</li>
<ul>
<li>api_root: "/girderdev/api/v1"</li>
<li>static_root: "/girderdev/static"</li>
</ul>
</ul>
<p>The tools.proxy.base/local settings may be overkill for our
Apache front end, but things work now, so I left those in. The
above changes show up in the Oauth settings page for the github
plugin that I wanted to use. The callback address previously did
not include the proxying girderdev portion of the address, because
Girder had not been aware of its own proxying (which we manage via
Apache). With the changes to girder.local.cfg, the address
generated in the plugin settings was correct.</p>
<p>The last hurdle was on Github itself. Girder is apparently
pulling down both the account name and email address from Github.
Only the email is matched against existing user emails, but the
Github account name becomes the users's name on Girder for the
duration of the login when an email match is found. In my case,
my test github account had no "name" per se and the blank caused
an error in Girder.</p>
<p>One other note: the Oauth through Github works even though our
top server, <a class="moz-txt-link-freetext" href="https://outward.facing.edu">https://outward.facing.edu</a>, is not itself visible
outside our institution's firewall. I'm assuming this works
because it is Girder that is invoking the connection to Github as
an oath client. I'm guessing the callback to Girder comes over
the same (likely high) port already opened by Girder.</p>
<p>Thanks for Zach's help.</p>
<p>John.<br>
</p>
<br>
<div class="moz-cite-prefix">On 02/03/2017 11:24 AM, John Roberts
wrote:<br>
</div>
<blockquote
cite="mid:2e891e4b-7e84-8b7f-abb6-c4f2d3f05a73@hsc.utah.edu"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<p> I believe that's' what I would see if I were running Girder
directly on the host or in a container that published that port.</p>
<p> However, we currently have our Girder running through a
reverse proxy. The settings in girder.local.cfg as described in
the documentation seem to allow you to drop that root directory
down a level.</p>
<p> So with appropriate changes to girder.local.cfg you could
have something like <br>
</p>
<p>http://server.address:port/GIRDERPROD/api/v1/oauth/github/callback</p>
<p>Before we started testing oauth, we were using an Apache
reverse proxy setup to handle some of our access control:</p>
<p><img src="cid:part1.9C53744B.D03704CE@hsc.utah.edu" alt=""></p>
<p>The Apache reverse proxy is used to limit access to certain
external subnets. I could probably accomplish this with iptable
rules, but the above approach is more consistent with the other
Docker web services also run on the same server using similar
Apache reverse proxy setups.</p>
<p>There are a variety of ways to run the dual Girder setup above
with Docker, including variations on whether the Docker
container is publishing ports (in which case the container will
answer the outside world directly on that port, with no
intervening Apache) or not publishing ports (in which case,
Apache or some other method must redirect the incoming traffic
to the appropriate container).</p>
<p>Assume I eliminate Docker from the discussion, and we just talk
about running two Girders on the same server on two separate
ports. Is it possible to set up the reverse proxy as described
in the documentation AND have oauth at the same time? I mean
Girder's own reverse proxy settings as described in the
documentation.</p>
<p>Thanks,<br>
John.<br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 02/02/2017 06:32 PM, Zach Mullen
wrote:<br>
</div>
<blockquote
cite="mid:CAPzddEEdrj65fvD0q4Z_DG5yj6UGzU0ORjFMDe0KnRMgCshO=A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">That is, what is the value listed in
your OAuth application's <b>Authorization callback URL</b> field,
which looks like the below screenshot:</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><img
src="cid:part2.6E40D84F.C414920B@hsc.utah.edu" alt="Inline
image 1" height="101" width="562"><br>
<br>
<div class="gmail_quote">On Thu, Feb 2, 2017 at 8:24 PM,
Zach Mullen <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:zach.mullen@kitware.com" target="_blank">zach.mullen@kitware.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div dir="ltr">To diagnose that issue, how is your
redirect URI configured in github? And what is the
value of the "state" parameter when you are sent to
the github login page?
<div>
<div class="h5">
<div class="gmail_extra"><br>
<div>
<div
class="m_-9105101711489940965gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr"><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Thu, Feb 2, 2017 at
8:07 PM, John Roberts <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:John.Roberts@hsc.utah.edu"
target="_blank">John.Roberts@hsc.utah.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div>
<p>Thanks for the reply, Zach.</p>
<p>Playing around with a test girder/mongo
pair, I managed to edit the
girder.local.cfg file without crashing
the container. Subsequently, it seems
to recognize correctly that it is not at
the top level of the web server.</p>
<p>This is all related to our effort to
run oauth through github. Previously,
without the proper proxy settings in
girder.local.cfg, the callback address
generated in the oath plugin setting did
not include the proxy. Now it does.</p>
<p>Unfortunately, authorization through
github still generates a
redirect_uri_mismatch error.</p>
<p>My best guess at the moment is that
this is somehow related to our proxying
girder itself through https on the
Apache server. I mean, we have a
reverse proxy setup on Apache to route
incoming requests for <a
moz-do-not-send="true"
class="m_-9105101711489940965m_5622547798940020294moz-txt-link-freetext"
href="https://some.address.com/girder"
target="_blank">https://some.address.com/girde<wbr>r</a>
to our internal <a
moz-do-not-send="true"
class="m_-9105101711489940965m_5622547798940020294moz-txt-link-freetext"
href="http://some.docker.network:8080/girder" target="_blank">http://some.docker.network:808<wbr>0/girder</a>.</p>
<p>Somewhere in the proxying, I'm thinking
the URL might be modified and either
Girder or Github says it doesn't match
what's expected. The message indicates
that it's Github who is rejecting the
callback:</p>
<p>{<br>
"message": "Provider returned error:
'redirect_uri_mismatch'.",<br>
"type": "rest"<br>
}</p>
<span class="m_-9105101711489940965HOEnZb">
<p><br>
</p>
<p>John.<br>
</p>
</span>
<div>
<div class="m_-9105101711489940965h5"> <br>
<div
class="m_-9105101711489940965m_5622547798940020294moz-cite-prefix">On
02/02/2017 05:06 PM, Zach Mullen
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi John,
<div><br>
</div>
<div>You're running an old version
of Girder (1.5.2), are you able
to upgrade to the latest version
and see if that fixes the issue?</div>
<div><br>
</div>
<div>Thanks,</div>
</div>
<div class="gmail_extra"><br>
<div>
<div
class="m_-9105101711489940965m_5622547798940020294gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">Zach Mullen<br>
Kitware, Inc.<br>
<a
moz-do-not-send="true"
href="tel:%28919%29%20869-8858" value="+19198698858" target="_blank">919-869-8858</a></div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Thu,
Feb 2, 2017 at 6:25 PM, John
Roberts <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:John.Roberts@hsc.utah.edu"
target="_blank">John.Roberts@hsc.utah.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div> I'd like to set up a
proxied Girder as detailed
in the manual <a
moz-do-not-send="true"
href="https://girder.readthedocs.io/en/v1.5.2/deploy.html?highlight=root"
target="_blank">here</a>.
We need to configure girder
so that it understands it is
not working from the root
directory of the Apache
server but one directory
down (/girder). Unlike the
situation in the
documentation, I'm working
with the Docker girder.<br>
<br>
If I rather blindly edit
the girder.local.cfg file
within the running
container, the container
crashes as soon as I save
the file. This may have
been due to a typo, but I
have a further question.<br>
<br>
Assuming I did update
girder.local.cfg properly as
indicated, the instructions
then say to rebuild Girder
using "npm install". It's
my impression that this will
likely crash the girder
container itself, since the
current girder process will
likely be terminated while
the new build is being
compiled with npm. Would
that be a correct
assumption?<br>
<br>
The question is how to
configure Girder within the
container to invoke the
proxy and move the address
space one step down from
root at / to a proxied
address /girder. A more
general question might be
how to update
girder.local.cfg when
running Girder with Docker.<br>
<br>
I tried running the
Docker girder:girder image
and entering by way of an
alternative entry-point,<br>
<br>
docker run -it
--entrypoint=/bin/bash
girder/girder -s<br>
<br>
This lets me in and I can
edit the girder.local.cfg
file. However, "npm
install" then appears to
fail with the warning
"cannot run in wd <a
moz-do-not-send="true"
class="m_-9105101711489940965m_5622547798940020294m_4407019786859912668moz-txt-link-abbreviated"
href="mailto:girder@1.5.2"
target="_blank">girder@1.5.2</a>
grunt init && grunt
(wd=/girder)". Since I
don't know what "npm
install" was supposed to
accomplish, I'm not sure
where to look to see if it
succeeded despite the
warning.<br>
<br>
Thanks for suggestions,<br>
John.<br>
<br>
<br>
<br>
</div>
<br>
______________________________<wbr>_________________<br>
Girder-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Girder-users@public.kitware.com"
target="_blank">Girder-users@public.kitware.co<wbr>m</a><br>
<a moz-do-not-send="true"
href="http://public.kitware.com/mailman/listinfo/girder-users"
rel="noreferrer"
target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/girder-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>