<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:ii_15a01994b7384f5b" alt="Inline image 1" width="562" height="101"><br>
<br><div class="gmail_quote">On Thu, Feb 2, 2017 at 8:24 PM, Zach Mullen <span dir="ltr"><<a href="mailto:zach.mullen@kitware.com" target="_blank">zach.mullen@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 clear="all"><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 href="mailto:John.Roberts@hsc.utah.edu" target="_blank">John.Roberts@hsc.utah.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <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 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 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"><font color="#888888">
    <p><br>
    </p>
    <p>John.<br>
    </p></font></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 href="tel:(919)%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 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 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 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 href="mailto:Girder-users@public.kitware.com" target="_blank">Girder-users@public.kitware.co<wbr>m</a><br>
            <a 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>