[Girder-users] Setting up proxied Girder with Docker Container

Zach Mullen zach.mullen at kitware.com
Fri Feb 3 17:47:13 EST 2017 

On Fri, Feb 3, 2017 at 5:37 PM, John Roberts <John.Roberts at hsc.utah.edu>
wrote:

> 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.
>

Good news!

> Within the girder container, I edit the girder.local.config file to add
> lines controlling its self-awareness about proxying.
>
>    - [global]
>       - tools.proxy.on: True
>       - tools.proxy.base: "https://outward.facing.edu/girderdev"
>       <https://outward.facing.edu/girderdev>
>       - tools.proxy.local: ""
>    - [server]
>       - api_root: "/girderdev/api/v1"
>       - static_root: "/girderdev/static"
>
> 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.
>
An alternative to having tools.proxy.base set explicitly is to have your
Apache proxy server set the X-Forwarded-Host header during proxying, but
the behavior is equivalent either way.

> 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.
>
The behavior in the latest version of Girder (2.1.0) should allow for
accounts without names; in that case, we just use the github login as both
the first and last name.

> One other note: the Oauth through Github works even though our top server,
> https://outward.facing.edu, 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.
>
The OAuth provider (in your case Github) doesn't contact the girder server
at all, it simply redirects the user's browser back to the callback URL
that was specified once the user authenticates and authorizes the
application.

Glad you got it working.

-Zach

> Thanks for Zach's help.
>
> John.
>
> On 02/03/2017 11:24 AM, John Roberts wrote:
>
>     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.
>
>     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.
>
>     So with appropriate changes to girder.local.cfg you could have
> something like
>
> http://server.address:port/GIRDERPROD/api/v1/oauth/github/callback
>
> Before we started testing oauth, we were using an Apache reverse proxy
> setup to handle some of our access control:
>
> 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.
>
> 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).
>
> 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.
>
> Thanks,
> John.
>
>
>
> On 02/02/2017 06:32 PM, Zach Mullen wrote:
>
> That is, what is the value listed in your OAuth application's *Authorization
> callback URL* field, which looks like the below screenshot:
>
> [image: Inline image 1]
>
> On Thu, Feb 2, 2017 at 8:24 PM, Zach Mullen <zach.mullen at kitware.com>
> wrote:
>
>> 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?
>>
>>
>>
>> On Thu, Feb 2, 2017 at 8:07 PM, John Roberts <John.Roberts at hsc.utah.edu>
>> wrote:
>>
>>> Thanks for the reply, Zach.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Unfortunately, authorization through github still generates a
>>> redirect_uri_mismatch error.
>>>
>>> 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
>>> https://some.address.com/girder to our internal
>>> http://some.docker.network:8080/girder.
>>>
>>> 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:
>>>
>>> {
>>>     "message": "Provider returned error: 'redirect_uri_mismatch'.",
>>>     "type": "rest"
>>> }
>>>
>>>
>>> John.
>>>
>>> On 02/02/2017 05:06 PM, Zach Mullen wrote:
>>>
>>> Hi John,
>>>
>>> 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?
>>>
>>> Thanks,
>>>
>>> Zach Mullen
>>> Kitware, Inc.
>>> 919-869-8858 <%28919%29%20869-8858>
>>>
>>> On Thu, Feb 2, 2017 at 6:25 PM, John Roberts <John.Roberts at hsc.utah.edu>
>>> wrote:
>>>
>>>>     I'd like to set up a proxied Girder as detailed in the manual here
>>>> <https://girder.readthedocs.io/en/v1.5.2/deploy.html?highlight=root>.
>>>> 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.
>>>>
>>>>     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.
>>>>
>>>>     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?
>>>>
>>>>     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.
>>>>
>>>>     I tried running the Docker girder:girder image and entering by way
>>>> of an alternative entry-point,
>>>>
>>>> docker run -it --entrypoint=/bin/bash girder/girder -s
>>>>
>>>> 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
>>>> girder at 1.5.2 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.
>>>>
>>>> Thanks for suggestions,
>>>> John.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Girder-users mailing list
>>>> Girder-users at public.kitware.com
>>>> http://public.kitware.com/mailman/listinfo/girder-users
>>>>
>>>>
>>>
>>>
>>
>
>
>
> _______________________________________________
> Girder-users mailing list
> Girder-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/girder-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170203/50b0f3c0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 47687 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170203/50b0f3c0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 21347 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170203/50b0f3c0/attachment-0003.png>

More information about the Girder-users mailing list