[Girder-users] Setting up proxied Girder with Docker Container
John Roberts
John.Roberts at hsc.utah.edu
Fri Feb 3 17:37:41 EST 2017
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.
Within the girder container, I edit the girder.local.config file to add
lines controlling its self-awareness about proxying.
* [global]
o tools.proxy.on: True
o tools.proxy.base: "https://outward.facing.edu/girderdev"
o tools.proxy.local: ""
* [server]
o api_root: "/girderdev/api/v1"
o 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.
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.
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.
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:
>>
>> Inline image 1
>>
>> On Thu, Feb 2, 2017 at 8:24 PM, Zach Mullen <zach.mullen at kitware.com
>> <mailto: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 <mailto: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
>> <https://some.address.com/girder> to our internal
>> http://some.docker.network:8080/girder
>> <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 <tel:%28919%29%20869-8858>
>>>
>>> On Thu, Feb 2, 2017 at 6:25 PM, John Roberts
>>> <John.Roberts at hsc.utah.edu
>>> <mailto: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
>>> <mailto: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
>>> <mailto:Girder-users at public.kitware.com>
>>> http://public.kitware.com/mailman/listinfo/girder-users
>>> <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/b3585ad2/attachment-0001.html>
-------------- 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/b3585ad2/attachment-0002.png>
-------------- 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/b3585ad2/attachment-0003.png>
More information about the Girder-users
mailing list