Using force_https=true creates bad redirect

Issue #121 new
JF created an issue

I've migrated from 0.1 to HG/tip to test Issue#120 but ran into a new problem when forcing connection to https I didn't have when using the workaround of force_ssl=true.

If I create a repository, my browser ends up with a bad request on https:://127.0.0.1:5000/REPONAME/repo_creating?task_id=None.

Creating a repository works just fine without force_https=true but then the URL in the summary is shown as http.

Note that the repository actually gets created in the database. It looks simply like a bad redirect.

Maybe, once again, there is a parameter I don't know about I should use to work around this problem?

My setup is the following: I use Apache that serves on https:// and connects to localhost:5000 in order to talk with Kallithea.

Thanks for your help,

JF

Comments (14)

  1. Mads Kiilerich

    The weirdest part about this is the None in the url.

    Can you reproduce that when connecting directly to 'paster serve' and without force_https?

  2. JF reporter

    Here is how I reproduce this:

    $ hg in
    comparing with https://kallithea-scm.org/repos/kallithea
    searching for changes
    no changes found
    $ hg up
    0 files updated, 0 files merged, 0 files removed, 0 files unresolved
    $ virtualenv ../kallithea-venv2
    New python executable in ../kallithea-venv2/bin/python
    Installing setuptools, pip...done.
    $ source ../kallithea-venv2/bin/activate
    (kallithea-venv2)$ python2.7 setup.py develop >& venv2
    (kallithea-venv2)$ tail -1 venv2
    Finished processing dependencies for Kallithea==0.1.post0
    (kallithea-venv2)$ cd ../kallithea-venv2
    (kallithea-venv2)$ paster make-config Kallithea my.ini
    Distribution already installed:
      Kallithea 0.1.post0 from /data1/scratchB/jfbeaumont/work/kallithea
    Creating my.ini
    Now you should edit the config files
      my.ini
    (kallithea-venv2)$ hg init .
    (kallithea-venv2)$ hg add my.ini
    (kallithea-venv2)$ hg commit -m init
    (kallithea-venv2)$ paster serve my.ini >> log 2>&1 &
    >>>Login as admin, create a repository test123, works, URL shows as http
    >>>Kill server
    (kallithea-venv2)$ fg
    paster serve my.ini >> log 2>&1
    ^C(kallithea-venv2)$ 
    >>>Update config
    (kallithea-venv2)$ hg diff
    diff -r f5aa2453f24e my.ini
    --- a/my.ini    Thu Apr 02 05:50:05 2015 -0400
    +++ b/my.ini    Thu Apr 02 05:54:40 2015 -0400
    @@ -164,7 +164,7 @@
     vcs_full_cache = true
    
     ## force https in Kallithea, fixes https redirects, assumes it's always https
    -force_https = false
    +force_https = true
    
     ## use Strict-Transport-Security headers
     use_htsts = false
    >>>Restart server
    (kallithea-venv2)$ paster serve my.ini >> log 2>&1 &
    >>>Reload the summary page, URL shows as https://
    >>>When creating a repository, I am forwarded to https://127.0.0.1:5000/test456/repo_creating?task_id=None (repository was created)
    

    I think something relevant might be Apache configuration that links to K:

    <Location / >
      ProxyPass http://127.0.0.1:5000/
      ProxyPassReverse http://127.0.0.1:5000/
      SetEnvIf X-Url-Scheme https HTTPS=1
    </Location>
    

    I'm assuming that it is Apache that does the nice SSL encryption on the network and indeed https:// doesn't work. I tried locally:

    lynx "http://localhost:5000"
    

    With that can get to the login page but I have enter the URL manually to actually log because the browser is waiting forever for "https://localhost:5000".

    paster doesn't seem to answer to "https://localhost:5000" at all but I didn't do anything special than the default config and using force_https so I guess this is normal.

    Finally, pointing a browser to http://localhost:5000 works well without force_https=true.

  3. Thomas De Schampheleire

    @kiilerix What about this one? Is this a configuration issue that should be clarified in the documentation? Or is there something fishy about force_https ?

  4. Mads Kiilerich

    There was a bug in force_https which was fixed in 0.2, IIRC. Code in this area has also changed in other ways since 0.1 ... and the root cause in this case was never found.

    Yes, I think it should be clarified in the documentation that hosting with non-wsgi-compliant development servers behind a reverse proxy is a bad idea. Others do however embrace that idea ;-)

  5. Steffen Frömer

    I had a similar problem. After changing to force_https=true, user can't get logged out, without redirecting to http://localhost:5000

    I added following lines to httpd.conf, which solve the problem

    ProxyRequests Off
    ProxyPreserveHost On
    
  6. Mads Kiilerich

    For problems like this, I'm surprised you can get logged in without seeing a similar problem there.

    I also wonder why this helps and whether it is the right fix or if it just is a workaround.

    Anyway, can you propose a patch to the documentation?

  7. Log in to comment