Is the official WSGI way of being notified that is HTTPS.
https://www.python.org/dev/peps/pep-0333/#id19
Is what should be used by any WSGI framework when doing URL reconstruction.
https://www.python.org/dev/peps/pep-0333/#url-reconstruction
Graham
On 20/12/2014, at 1:35 PM, Jason Garber <[email protected]> wrote:
> I was not aware of wsgi.url_scheme. Thanks!
>
> On Dec 19, 2014 8:38 PM, "Graham Dumpleton" <[email protected]>
> wrote:
> For wsgi.url_scheme, if you use mod_rewrite, mod_headers or mod_setenvif to
> detect that https is being indicate through a header set by the proxy, you
> can set the env parameter 'HTTPS' and mod_wsgi will detect that and
> automatically override wsgi.url_scheme to be 'https'.
>
> Not sure how you are using Scheme header, but using mod_setenvif as one way,
> you can write:
>
> SetEnvIf X-Scheme https HTTPS=1
>
> Do it this way and you don't have to fiddle it in your WSGi application.
>
> Note that you should always consult wsgi.url_scheme and not look for HTTPS in
> environ for request, as mod_wsgi will purposely remove HTTPS after setting
> wsgi.url_scheme from it to try and stop people writing non portable WSGI
> applications.
>
> Graham
>
> On 20/12/2014, at 7:50 AM, Jason Garber <[email protected]> wrote:
>
>> Hi Jennifer,
>>
>> https://github.com/gnif/mod_rpaf
>>
>> mod_rpaf is an apache module which will consume the headers I have set in
>> nginx. Once installed it can be configured like this:
>>
>> LoadModule rpaf_module modules/mod_rpaf.so
>> RPAFenable On
>> RPAFsethostname On
>> RPAFproxy_ips 127.0.0.1
>> RPAFheader X-Forwarded-For
>>
>> Long story short is that it will cause apache to behave normally with
>> regards to logging and providing the IP to the application. In the case of
>> PHP and similar, you still need an alternate way to know if HTTP or HTTPS
>> was used, which we use the HTTP_SCHEME variable for and just handle it in
>> the application layer.
>>
>> Thanks!
>> Jason
>>
>> On Thu, Dec 18, 2014 at 10:44 PM, Jennifer Mehl <[email protected]>
>> wrote:
>> This was *VERY* helpful, thanks!
>>
>> Looks like it was some weird behavior with Apache and SSL. I don’t think
>> mod_wsgi was one of the troublemakers at all. :-)
>>
>> Both of the browser’s bad behavior is now gone. I’ve changed to using Nginx
>> as an SSL front-end proxy to a back-end Apache acting as an application web
>> server for the Django application (still using mod_wsgi 4.4.1).
>>
>> It took me a bit to figure out how to get the REMOTE_ADDR header to reflect
>> the actual IP address instead of the proxy’s, and to pass that into the web
>> application (used in several areas for rules and logging) but all is working
>> well now.
>>
>> Thanks to you and Graham for all of your help on getting me up and going!
>>
>> —Jennifer
>>
>>
>> > On Dec 17, 2014, at 10:45 AM, Jason Garber <[email protected]> wrote:
>> >
>> > Hi Jennifer,
>> >
>> > Here is how we do it, and it works well. Please adapt as needed.
>> >
>> > In summary, we use nginx to terminate ssl, handle any redirects, serve
>> > static content, and proxy any remaining requests to apache. Essentially
>> > apache is just a very robust application server at this point.
>> >
>> > In Apache, each app is served on it's own port on 127.0.0.1. This keeps
>> > the application traffic from getting mixed up. Nginx contains the ability
>> > to serve http and https from the same server entry which is supremely
>> > convenient.
>> >
>> > Keep in mind that nginx will proxy over HTTP/1.0 which means there is no
>> > Host header sent by default. It is added in the nginx server.
>> >
>> > Note that I have not used it with Django, but have used it with everything
>> > from Ruby and Phusion Passenger to PHP to Python and mod_wsgi. It *just
>> > works*.
>> >
>> > -----------------------------------------
>> >
>> > NGINX:
>> > Install from package repository
>> >
>> > Here is a tweaked /etc/nginx/nginx.conf you can use:
>> >
>> > https://github.com/appcove/acn-linux/blob/master/os-template/etc/nginx/nginx.conf
>> >
>> > Note Line 22 needs updated
>> > It includes from /etc/nginx/conf.d/*.conf
>> > It includes from /etc/nginx/conf.server.d/*.conf
>> >
>> > (you need to manually create that directory, or just remove that include
>> > line and put everything in conf.d)
>> >
>> >
>> > -- Note: the following is included automatically by the main
>> > /etc/nginx/nginx.conf --
>> >
>> > /etc/nginx/conf.server.d/www.example.com.conf
>> >
>> > server
>> > {
>> > listen 192.168.50.12:80;
>> > listen 192.168.50.12:443 ssl;
>> >
>> > server_name www.example.com;
>> >
>> > # Note, this is the /etc/nginx/ssl/ directory
>> >
>> > ssl_certificate ssl/www.example.com.crt;
>> > ssl_certificate_key ssl/www.example.com.key;
>> >
>> > # Nginx uses HTTP 1.0 to proxy, so we need to manually add headers so
>> > the app can
>> > # know if we were in http or https and who originally requested the
>> > content
>> >
>> > proxy_set_header Host $host;
>> > proxy_set_header X-Real-IP $remote_addr;
>> > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>> > proxy_set_header Scheme $scheme;
>> >
>> > # Allow large uploads
>> >
>> > client_max_body_size 1000m;
>> >
>> > # Nginx serves static content, so it is important to forbid any
>> > # python files from being served
>> >
>> > location ~ \.(py|pyc|pyo|wsgi)$
>> > {
>> > return 403;
>> > }
>> >
>> > # Anything with an extension is served directly. You may want to
>> > # remove this from your config.
>> >
>> > location ~ \.([a-zA-Z0-9])+$
>> > {
>> > root /home/jason/ExampleProject/Web;
>> >
>> > add_header Cache-Control 'no-cache, no-store, max-age=0,
>> > must-revalidate';
>> > add_header Expires 'Thu, 01 Jan 1970 00:00:01 GMT';
>> >
>> > }
>> >
>> > # Everything else is proxied to Apache on 127.0.0.1 port 60301
>> >
>> > location /
>> > {
>> > add_header Cache-Control 'no-cache, no-store, max-age=0,
>> > must-revalidate';
>> > add_header Expires 'Thu, 01 Jan 1970 00:00:01 GMT';
>> > proxy_pass http://127.0.0.1:60301;
>> > }
>> > }
>> >
>> >
>> > The following apache config is included by the main httpd config file
>> >
>> > # Notice we are telling apache to listen on 127.0.0.1 port 60301.
>> > # For the sake of clairity, we are calling the WSGIDaemonProcess by the
>> > same name as the port.
>> > # By hosting each app on it's own port, we eliminate any server-name
>> > issues between nginx and apache
>> >
>> > WSGIDaemonProcess Port60301 processes=2 threads=2
>> > python-path=/home/jason/ExampleProject/Python
>> > Listen 127.0.0.1:60301
>> > NameVirtualHost 127.0.0.1:60301
>> >
>> > # www.example.com
>> > <VirtualHost 127.0.0.1:60301>
>> > ServerName _default_
>> > DocumentRoot /home/jason/DevLevel.2/PBN/Web/Main
>> > AddDefaultCharset UTF-8
>> >
>> > RewriteEngine on
>> > RewriteOptions inherit
>> >
>> > # Forbid any python source files from being served.
>> > RewriteRule \.(py|pyc|pyo|wsgi)$ - [F]
>> >
>> > WSGIScriptAlias / /home/jason/ExampleProject/Web/__init__.wsgi
>> > WSGIProcessGroup Port60301
>> >
>> > LogLevel info
>> > ErrorLog /home/jason/ExampleProject/apache-error.log
>> > </VirtualHost>
>> >
>> >
>> > These lines are also in the main apache config:
>> >
>> > LoadModule wsgi_module modules/python33-mod_wsgi.so
>> > WSGISocketPrefix run/wsgi
>> > WSGIApplicationGroup %{GLOBAL}
>> >
>> >
>> > ------------------------
>> >
>> > Thanks!
>> > Jason
>> >
>> >
>> > On Wed, Dec 17, 2014 at 12:16 AM, Jennifer Mehl <[email protected]>
>> > wrote:
>> > Fantastic - thanks again!
>> >
>> > Jennifer
>> >
>> > > On Dec 16, 2014, at 9:14 PM, Jason Garber <[email protected]> wrote:
>> > >
>> > > I will send in the morning (eastern).
>> > >
>> > > On Dec 16, 2014 11:18 PM, "Jennifer Mehl" <[email protected]>
>> > > wrote:
>> > > Jason,
>> > >
>> > > Having complete example configs would be fantastic. Turning on SSL in
>> > > Apache is what is currently making parts of the app 'break' in IE and
>> > > Safari. It would be great if I could rule out the application code -
>> > > changing front end web servers is probably the only way to do that.
>> > >
>> > > Thanks in advance for the help!
>> > >
>> > > Jennifer
>> > >
>> > >
>> > > > On Dec 16, 2014, at 8:14 PM, Jason Garber <[email protected]> wrote:
>> > > >
>> > > > Hi Jennifer,
>> > > >
>> > > > May I suggest you simplify your apache config by running apache on
>> > > > 127.0.0.1:8086 (for example) and placing nginx in front of it proxying
>> > > > requests to apache. Use nginx for ssl termination.
>> > > >
>> > > > It is dead simple and uncomplicates the apache config.
>> > > >
>> > > > I can provide complete example configs if you wish.
>> > > >
>> > > > Thanks!
>> > > > Jason
>> > > >
>> > > > On Dec 16, 2014 8:03 PM, "Jennifer Mehl" <[email protected]>
>> > > > wrote:
>> > > > Thank you. Good to get those things all cleaned up.
>> > > >
>> > > > I also compiled and installed v4.4.1 of mod_wsgi from source and
>> > > > removed the 3.4 Ubuntu version from my system.
>> > > >
>> > > > Setting DEBUG = False seems to break my application - I get a “Bad
>> > > > Request 400” error back in my browser - so I will check in with the
>> > > > developer on that one.
>> > > >
>> > > > I’ve removed the extraneous environment variables and also the SSL
>> > > > proxy setting. I am only using mod_wsgi with Apache, so, as you say,
>> > > > it shouldn’t need that anyhow.
>> > > >
>> > > > I’ve done the test for the /wsgicheck and it does return a value of
>> > > > https. Thanks for helping me verify that functionality.
>> > > >
>> > > > So, this leaves me with looking at Apache as a culprit - or again, the
>> > > > Django code itself. It’s very odd how only the two browsers are
>> > > > showing issues and they are completely different issues…
>> > > >
>> > > > thanks,
>> > > > Jennifer
>> > > >
>> > > >
>> > > >
>> > > > > On Dec 16, 2014, at 4:41 PM, Graham Dumpleton
>> > > > > <[email protected]> wrote:
>> > > > >
>> > > > > Hmmm, this looks really dangerous:
>> > > > >
>> > > > > DEBUG = "FALSE"
>> > > > >
>> > > > > The DEBUG setting is meant to be a boolean value, not a string.
>> > > > >
>> > > > > Because you are setting it to a non empty string, it will be
>> > > > > interpreted as True and so you have debug mode enabled.
>> > > > >
>> > > > > That is not good as sensitive information could be exposed back to
>> > > > > users in error pages shown in the browser.
>> > > > >
>> > > > > Running in debug mode might cause other issues as well.
>> > > > >
>> > > > > Ensure you are setting it to:
>> > > > >
>> > > > > DEBUG = False
>> > > > >
>> > > > > Also, setting:
>> > > > >
>> > > > > os.environ['HTTPS'] = "on"
>> > > > > os.environ['wsgi.url_scheme'] = 'https'
>> > > > >
>> > > > > will not do anything.
>> > > > >
>> > > > > The wsgi.url_scheme is an attribute which is passed down by mod_wsgi
>> > > > > in the details for each request. A web framework will use the flag
>> > > > > from the request details. The main thing it controls is merely the
>> > > > > construction of absolute URLs when needing to be added to response
>> > > > > headers or maybe response content in some cases.
>> > > > >
>> > > > > In other words, you do not need to set it and setting it in
>> > > > > environment variables wouldn't do anything anyway.
>> > > > >
>> > > > > Next, setting:
>> > > > >
>> > > > > os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>> > > > > "myproject.settings")
>> > > > >
>> > > > > is okay if you have just the one Django site, but be careful in
>> > > > > using this if you are running more than one. Safer to use:
>> > > > >
>> > > > > os.environ["DJANGO_SETTINGS_MODULE"] = "myproject.settings"
>> > > > >
>> > > > > More details in:
>> > > > >
>> > > > >
>> > > > > http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html
>> > > > >
>> > > > > You also don't need:
>> > > > >
>> > > > > SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
>> > > > >
>> > > > > if Apache is your front facing web server. You would only need this
>> > > > > if you had a further front end proxy such as nginx in front of
>> > > > > Apache and nginx had been configured to actually introduce these
>> > > > > headers. That your Apache is accepting HTTPS requests would indicate
>> > > > > that you don't have an nginx in front.
>> > > > >
>> > > > > Now as to determine whether wsgi.url_scheme is set properly, the
>> > > > > easiest way is to take a copy of:
>> > > > >
>> > > > > def application(environ, start_response):
>> > > > > status = '200 OK'
>> > > > > output = str(environ.get('wsgi.url_scheme'))
>> > > > >
>> > > > > response_headers = [('Content-type', 'text/plain'),
>> > > > > ('Content-Length', str(len(output)))]
>> > > > > start_response(status, response_headers)
>> > > > >
>> > > > > return [output]
>> > > > >
>> > > > > Put it in a file called check.py nest to your existing wsgi.py file.
>> > > > >
>> > > > > In the Apache configuration, BEFORE THE LINE:
>> > > > >
>> > > > > WSGIScriptAlias /
>> > > > > /var/www/transfergateway/myproject/apache/wsgi.py
>> > > > >
>> > > > > add:
>> > > > >
>> > > > > WSGIScriptAlias /wsgicheck
>> > > > > /var/www/transfergateway/myproject/apache/check.py
>> > > > >
>> > > > > Then down further where have:
>> > > > >
>> > > > > <Directory /var/www/transfergateway/myproject/apache>
>> > > > > <Files wsgi.py>
>> > > > > Order deny,allow
>> > > > > Allow from all
>> > > > > </Files>
>> > > > > </Directory>
>> > > > >
>> > > > > Change it to:
>> > > > >
>> > > > > <Directory /var/www/transfergateway/myproject/apache>
>> > > > > <Files wsgi.py>
>> > > > > Order deny,allow
>> > > > > Allow from all
>> > > > > </Files>
>> > > > > <Files check.py>
>> > > > > Order deny,allow
>> > > > > Allow from all
>> > > > > </Files>
>> > > > > </Directory>
>> > > > >
>> > > > > Restart Apache and then hit the URL of the site for /wsgicheck
>> > > > >
>> > > > > You should see 'https' returned in the page.
>> > > > >
>> > > > > Hope this helps.
>> > > > >
>> > > > > Graham
>> > > > >
>> > > > > On 17/12/2014, at 11:09 AM, Jennifer Mehl <[email protected]>
>> > > > > wrote:
>> > > > >
>> > > > >> No problem, if I have to compile from source, then I will try that.
>> > > > >>
>> > > > >> One last thing regarding HTTPS - how do I ensure that I have the
>> > > > >> wsgi.url_scheme set correctly?
>> > > > >>
>> > > > >> Here is my wsgi.py file:
>> > > > >>
>> > > > >> import os
>> > > > >> import sys
>> > > > >>
>> > > > >> path='/var/www/transfergateway/myproject'
>> > > > >>
>> > > > >> #if path not in sys.path:
>> > > > >> #sys.path.append(path)
>> > > > >>
>> > > > >> os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>> > > > >> "myproject.settings")
>> > > > >>
>> > > > >> #HTTPS
>> > > > >> os.environ['HTTPS'] = "on"
>> > > > >>
>> > > > >> # This application object is used by any WSGI server configured to
>> > > > >> use this
>> > > > >> # file. This includes Django's development server, if the
>> > > > >> WSGI_APPLICATION
>> > > > >> # setting points here.
>> > > > >> from django.core.wsgi import get_wsgi_application
>> > > > >> application = get_wsgi_application()
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> and here is relevant stuff from my settings.py file:
>> > > > >>
>> > > > >> import os
>> > > > >> PROJECT_ROOT = os.path.realpath(os.path.dirname(__file__))
>> > > > >>
>> > > > >>
>> > > > >> #turn off debug when going to production
>> > > > >> DEBUG = "FALSE"
>> > > > >> TEMPLATE_DEBUG = DEBUG
>> > > > >>
>> > > > >>
>> > > > >> # Python dotted path to the WSGI application used by Django's
>> > > > >> runserver.
>> > > > >> WSGI_APPLICATION = 'myproject.wsgi.application'
>> > > > >>
>> > > > >>
>> > > > >> #session expire at browser close
>> > > > >> SESSION_EXPIRE_AT_BROWSER_CLOSE = True
>> > > > >> SESSION_COOKIE_HTTPONLY=True
>> > > > >>
>> > > > >> #idle timeout
>> > > > >> SESSION_IDLE_TIMEOUT=900
>> > > > >>
>> > > > >> #HTTPS stuff - secure proxy SSL header - do I need this?
>> > > > >> SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
>> > > > >> #HTTPS stuff - secure cookies
>> > > > >> SESSION_COOKIE_SECURE = True
>> > > > >> CSRF_COOKIE_SECURE = True
>> > > > >>
>> > > > >> #HTTPS WSGI
>> > > > >> os.environ['wsgi.url_scheme'] = 'https'
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>> On Dec 16, 2014, at 3:59 PM, Graham Dumpleton
>> > > > >>> <[email protected]> wrote:
>> > > > >>>
>> > > > >>> You will unfortunately not find a binary OS supplied Ubuntu 10.4
>> > > > >>> package for mod_wsgi which is newer.
>> > > > >>>
>> > > > >>> Your only choice would be to compile from source code.
>> > > > >>>
>> > > > >>> Graham
>> > > > >>>
>> > > > >>> On 17/12/2014, at 10:54 AM, Jennifer Mehl
>> > > > >>> <[email protected]> wrote:
>> > > > >>>
>> > > > >>>> Thanks for this info. I’ll try a newer mod_wsgi.
>> > > > >>>>
>> > > > >>>> It’s very odd to me that the app works fine in mod_wsgi/Apache
>> > > > >>>> with no SSL but parts become broken in certain browsers once SSL
>> > > > >>>> is enabled.
>> > > > >>>>
>> > > > >>>> At any rate, thanks for the guidance and I’ll report back if I
>> > > > >>>> find a fix!
>> > > > >>>>
>> > > > >>>> —Jennifer
>> > > > >>>>
>> > > > >>>>> On Dec 16, 2014, at 3:46 PM, Graham Dumpleton
>> > > > >>>>> <[email protected]> wrote:
>> > > > >>>>>
>> > > > >>>>> If you are using mod_wsgi 3.4 that could be a problem in itself.
>> > > > >>>>>
>> > > > >>>>> Recent versions of Ubuntu as I understand it use Apache 2.4, but
>> > > > >>>>> such an old version of mod_wsgi may have issues on Apache 2.4.
>> > > > >>>>> At the minimum would need to have mod_wsgi 3.5 from memory as
>> > > > >>>>> some Apache 2.4 fixes were back ported to 3.5. It is unlikely
>> > > > >>>>> they back ported those themselves to 3.4 for 14.04.
>> > > > >>>>>
>> > > > >>>>> Either way, mod_wsgi itself shouldn't be causing any problems
>> > > > >>>>> with HTTPS as it is Apache that deals with all that and mod_wsgi
>> > > > >>>>> has nothing to do with the handling of secure connections. When
>> > > > >>>>> mod_wsgi sees a request that came via HTTPS it sees it as being
>> > > > >>>>> no different to a HTTP request with the exception of what the
>> > > > >>>>> wsgi.url_scheme attribute is set to. It is therefore more likely
>> > > > >>>>> to be an Apache configuration issue or issue with the code of
>> > > > >>>>> Apache itself.
>> > > > >>>>>
>> > > > >>>>> FWIW, mod_wsgi 3.4 means that Ubuntu version is almost 20
>> > > > >>>>> versions behind. Even Ubuntu 14.10 has only mod_wsgi 3.5. It is
>> > > > >>>>> quite frustrating that they haven't been bothered to update
>> > > > >>>>> their packages to more recent versions even if only for the most
>> > > > >>>>> recent 14.10.
>> > > > >>>>>
>> > > > >>>>> About the only thing I can suggest if it is readily
>> > > > >>>>> reproducible, is to use request logging such as described in:
>> > > > >>>>>
>> > > > >>>>> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Tracking_Request_and_Response
>> > > > >>>>>
>> > > > >>>>> to see if when a request has issues, that the WSGI application
>> > > > >>>>> actually returned the requests properly.
>> > > > >>>>>
>> > > > >>>>> If it isn't, then use something like:
>> > > > >>>>>
>> > > > >>>>> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Extracting_Python_Stack_Traces
>> > > > >>>>>
>> > > > >>>>> to get out Python stack traces for where a request handler may
>> > > > >>>>> be stuck.
>> > > > >>>>>
>> > > > >>>>> Both can be fiddly so sounds like you aren't going to have time
>> > > > >>>>> to do that.
>> > > > >>>>>
>> > > > >>>>> Graham
>> > > > >>>>>
>> > > > >>>>> On 17/12/2014, at 10:04 AM, Jennifer Mehl
>> > > > >>>>> <[email protected]> wrote:
>> > > > >>>>>
>> > > > >>>>>> I’m on the latest for Ubuntu 14.04LTS - 2.4.7-1ubuntu4.1. I
>> > > > >>>>>> have been using the updated mod_wsgi3.4 from Ubuntu.
>> > > > >>>>>>
>> > > > >>>>>> At this point I was thinking about trying my Django application
>> > > > >>>>>> in a different WSGI server to see if I can narrow down if the
>> > > > >>>>>> problem is with the Django code or something with mod_wsgi. I
>> > > > >>>>>> was thinking about uwsgi (trying to find something quick and
>> > > > >>>>>> easy to test) or nginx.
>> > > > >>>>>>
>> > > > >>>>>> Again, the weird browser behavior I describe below only happens
>> > > > >>>>>> when using Apache/HTTPS, port 443, in mod_wsgi (not Apache/HTTP
>> > > > >>>>>> in mod_wsgi or the Django development server in port 80).
>> > > > >>>>>>
>> > > > >>>>>> I’m kind of at my wit’s end trying to narrow down *where* the
>> > > > >>>>>> problem is (if it’s something in the Django code, I only have
>> > > > >>>>>> one more day until my developer leaves for a few weeks for
>> > > > >>>>>> winter break…) Do you think there any debugging I can do by
>> > > > >>>>>> looking at the developer console in the affected browsers - for
>> > > > >>>>>> instance comparing the affected pages on a working port 80 vs
>> > > > >>>>>> the same pages on the non-working SSL/port 443 connection?
>> > > > >>>>>>
>> > > > >>>>>> thank you,
>> > > > >>>>>> Jennifer
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>>>> On Dec 16, 2014, at 2:55 PM, Graham Dumpleton
>> > > > >>>>>>> <[email protected]> wrote:
>> > > > >>>>>>>
>> > > > >>>>>>> One more question. What version of Apache are you using?
>> > > > >>>>>>>
>> > > > >>>>>>> If you are stuck on a quite old Apache 2.2.X version that
>> > > > >>>>>>> would be a concern as there were various SSL related issues
>> > > > >>>>>>> patched during the life of Apache 2.2.X.
>> > > > >>>>>>>
>> > > > >>>>>>> Graham
>> > > > >>>>>>>
>> > > > >>>>>>> On 16/12/2014, at 11:40 AM, Graham Dumpleton
>> > > > >>>>>>> <[email protected]> wrote:
>> > > > >>>>>>>
>> > > > >>>>>>>> I'll go through the description you gave me and see if can
>> > > > >>>>>>>> suggest anything, but first up, what version of mod_wsgi are
>> > > > >>>>>>>> you using?
>> > > > >>>>>>>>
>> > > > >>>>>>>> If you are using mod_wsgi 4.4.0 make sure you update to
>> > > > >>>>>>>> 4.4.1. The newer version resolves a potential for process
>> > > > >>>>>>>> crashing introduced in 4.4.0.
>> > > > >>>>>>>>
>> > > > >>>>>>>> Graham
>> > > > >>>>>>>>
>> > > > >>>>>>>> On 16/12/2014, at 11:33 AM, Jennifer Mehl
>> > > > >>>>>>>> <[email protected]> wrote:
>> > > > >>>>>>>>
>> > > > >>>>>>>>> Hi there,
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> I am backpedalling a bit from my previous attempt to chroot
>> > > > >>>>>>>>> mod_wsgi - instead, for now, just to get this Django
>> > > > >>>>>>>>> application running, for simplicity, I am going to start out
>> > > > >>>>>>>>> with just running it as a daemon as a restricted user.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> In doing the final testing of my application on various
>> > > > >>>>>>>>> browsers, I have noticed some strange problems.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> When I run Django/mod_wsgi/Apache on port 80 (same config as
>> > > > >>>>>>>>> below, minus the mod_ssl stuff) or use the django
>> > > > >>>>>>>>> development runserver 0.0.0.0:80, and disable the following
>> > > > >>>>>>>>> settings in settings.py (#SESSION_COOKIE_SECURE = True
>> > > > >>>>>>>>> #CSRF_COOKIE_SECURE = True) these browsers work correctly in
>> > > > >>>>>>>>> the app.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> However, when running Django application running through
>> > > > >>>>>>>>> mod_wsgi and HTTPS/port 443 in Apache, I see problems with
>> > > > >>>>>>>>> both IE and Safari browsers. After login on Internet
>> > > > >>>>>>>>> Explorer, page timeouts occur in various locations,
>> > > > >>>>>>>>> reporting "This page can't be displayed". On Safari, the
>> > > > >>>>>>>>> app won't get past the secondary Duo MFA authentication
>> > > > >>>>>>>>> step, saying "Server unexpectedly dropped the connection."
>> > > > >>>>>>>>> It is not a consistent behavior - seems to happen more
>> > > > >>>>>>>>> frequently if I click quickly through links. Sometimes if
>> > > > >>>>>>>>> I wait long enough to click, it might work momentarily, but
>> > > > >>>>>>>>> then not again a moment later. This behavior does NOT
>> > > > >>>>>>>>> happen using Chrome or Firefox browsers on any OS.
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Apache config:
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> <IfModule mod_ssl.c>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> <VirtualHost *:443>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> ServerName **redacted**
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> #Django WSGI - Daemon
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> WSGIScriptAlias /
>> > > > >>>>>>>>> /var/www/transfergateway/myproject/apache/wsgi.py
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> WSGIProcessGroup file-xfer
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> WSGIDaemonProcess file-xfer user=mod_wsgi group=mod_wsgi
>> > > > >>>>>>>>> processes=2 threads=25 python-path=/var/www/transfergateway
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> <Directory /var/www/transfergateway/myproject/apache>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> <Files wsgi.py>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Order deny,allow
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Allow from all
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> </Files>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> </Directory>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Alias /robots.txt
>> > > > >>>>>>>>> /var/www/transfergateway/myproject/myapp/static/robots.txt
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Alias /favicon.ico
>> > > > >>>>>>>>> /var/www/transfergateway/myproject/myapp/static/favicon.ico
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> AliasMatch ^/([^/]*\.css)
>> > > > >>>>>>>>> /var/www/transfergateway/myproject/myapp/static/styles/$1
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Alias /media/ /var/www/transfergateway/myproject/myapp/media/
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Alias /static/
>> > > > >>>>>>>>> /var/www/transfergateway/myproject/myapp/static/
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> <Directory /var/www/transfergateway/myproject/myapp/static>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Order deny,allow
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Allow from all
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> </Directory>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> <Directory /var/www/transfergateway/myproject/myapp/media>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Order deny,allow
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Allow from all
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> </Directory>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> ErrorLog ${APACHE_LOG_DIR}/error.log
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> CustomLog ${APACHE_LOG_DIR}/access.log combined
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> SSLEngine on
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> SSLCertificateFile /etc/ssl/certs/***
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> SSLCertificateKeyFile /etc/ssl/private/**
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> SSLCertificateChainFile /etc/ssl/certs/**
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> SSLCipherSuite HIGH:!aNULL:!MD5
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> </VirtualHost>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> </IfModule>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> So, I'm concluding that the HTTPS problem is one of two
>> > > > >>>>>>>>> things: how I am configuring mod_wsgi with HTTPS, or some
>> > > > >>>>>>>>> issue inside the Django code (but HTTPS works on some
>> > > > >>>>>>>>> browsers with no issues, so I'm stumped...)
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> Is there anything special that I need to do in mod_wsgi or
>> > > > >>>>>>>>> the Django application itself, in order to make the
>> > > > >>>>>>>>> application HTTPS only? (I am not a Python or Django
>> > > > >>>>>>>>> developer, so I would be passing info on to the actual
>> > > > >>>>>>>>> application developer for resolution.) Any ideas?
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> thank you,
>> > > > >>>>>>>>> Jennifer
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>>
>> > > > >>>>>>>>> --
>> > > > >>>>>>>>> You received this message because you are subscribed to the
>> > > > >>>>>>>>> Google Groups "modwsgi" group.
>> > > > >>>>>>>>> To unsubscribe from this group and stop receiving emails
>> > > > >>>>>>>>> from it, send an email to
>> > > > >>>>>>>>> [email protected].
>> > > > >>>>>>>>> To post to this group, send email to
>> > > > >>>>>>>>> [email protected].
>> > > > >>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>> > > > >>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>> > > > >>>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>> --
>> > > > >>>>>>> You received this message because you are subscribed to a
>> > > > >>>>>>> topic in the Google Groups "modwsgi" group.
>> > > > >>>>>>> To unsubscribe from this topic, visit
>> > > > >>>>>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> > > > >>>>>>> To unsubscribe from this group and all its topics, send an
>> > > > >>>>>>> email to [email protected].
>> > > > >>>>>>> To post to this group, send email to [email protected].
>> > > > >>>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>> > > > >>>>>>> For more options, visit https://groups.google.com/d/optout.
>> > > > >>>>>>
>> > > > >>>>>> --
>> > > > >>>>>> You received this message because you are subscribed to the
>> > > > >>>>>> Google Groups "modwsgi" group.
>> > > > >>>>>> To unsubscribe from this group and stop receiving emails from
>> > > > >>>>>> it, send an email to [email protected].
>> > > > >>>>>> To post to this group, send email to [email protected].
>> > > > >>>>>> Visit this group at http://groups.google.com/group/modwsgi.
>> > > > >>>>>> For more options, visit https://groups.google.com/d/optout.
>> > > > >>>>>
>> > > > >>>>> --
>> > > > >>>>> You received this message because you are subscribed to a topic
>> > > > >>>>> in the Google Groups "modwsgi" group.
>> > > > >>>>> To unsubscribe from this topic, visit
>> > > > >>>>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> > > > >>>>> To unsubscribe from this group and all its topics, send an email
>> > > > >>>>> to [email protected].
>> > > > >>>>> To post to this group, send email to [email protected].
>> > > > >>>>> Visit this group at http://groups.google.com/group/modwsgi.
>> > > > >>>>> For more options, visit https://groups.google.com/d/optout.
>> > > > >>>>
>> > > > >>>> --
>> > > > >>>> You received this message because you are subscribed to the
>> > > > >>>> Google Groups "modwsgi" group.
>> > > > >>>> To unsubscribe from this group and stop receiving emails from it,
>> > > > >>>> send an email to [email protected].
>> > > > >>>> To post to this group, send email to [email protected].
>> > > > >>>> Visit this group at http://groups.google.com/group/modwsgi.
>> > > > >>>> For more options, visit https://groups.google.com/d/optout.
>> > > > >>>
>> > > > >>> --
>> > > > >>> You received this message because you are subscribed to a topic in
>> > > > >>> the Google Groups "modwsgi" group.
>> > > > >>> To unsubscribe from this topic, visit
>> > > > >>> https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> > > > >>> To unsubscribe from this group and all its topics, send an email
>> > > > >>> to [email protected].
>> > > > >>> To post to this group, send email to [email protected].
>> > > > >>> Visit this group at http://groups.google.com/group/modwsgi.
>> > > > >>> For more options, visit https://groups.google.com/d/optout.
>> > > > >>
>> > > > >> --
>> > > > >> You received this message because you are subscribed to the Google
>> > > > >> Groups "modwsgi" group.
>> > > > >> To unsubscribe from this group and stop receiving emails from it,
>> > > > >> send an email to [email protected].
>> > > > >> To post to this group, send email to [email protected].
>> > > > >> Visit this group at http://groups.google.com/group/modwsgi.
>> > > > >> For more options, visit https://groups.google.com/d/optout.
>> > > > >
>> > > > > --
>> > > > > You received this message because you are subscribed to a topic in
>> > > > > the Google Groups "modwsgi" group.
>> > > > > To unsubscribe from this topic, visit
>> > > > > https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> > > > > To unsubscribe from this group and all its topics, send an email to
>> > > > > [email protected].
>> > > > > To post to this group, send email to [email protected].
>> > > > > Visit this group at http://groups.google.com/group/modwsgi.
>> > > > > For more options, visit https://groups.google.com/d/optout.
>> > > >
>> > > > --
>> > > > You received this message because you are subscribed to the Google
>> > > > Groups "modwsgi" group.
>> > > > To unsubscribe from this group and stop receiving emails from it, send
>> > > > an email to [email protected].
>> > > > To post to this group, send email to [email protected].
>> > > > Visit this group at http://groups.google.com/group/modwsgi.
>> > > > For more options, visit https://groups.google.com/d/optout.
>> > > >
>> > > > --
>> > > > You received this message because you are subscribed to a topic in the
>> > > > Google Groups "modwsgi" group.
>> > > > To unsubscribe from this topic, visit
>> > > > https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> > > > To unsubscribe from this group and all its topics, send an email to
>> > > > [email protected].
>> > > > To post to this group, send email to [email protected].
>> > > > Visit this group at http://groups.google.com/group/modwsgi.
>> > > > For more options, visit https://groups.google.com/d/optout.
>> > >
>> > > --
>> > > You received this message because you are subscribed to the Google
>> > > Groups "modwsgi" group.
>> > > To unsubscribe from this group and stop receiving emails from it, send
>> > > an email to [email protected].
>> > > To post to this group, send email to [email protected].
>> > > Visit this group at http://groups.google.com/group/modwsgi.
>> > > For more options, visit https://groups.google.com/d/optout.
>> > >
>> > > --
>> > > You received this message because you are subscribed to a topic in the
>> > > Google Groups "modwsgi" group.
>> > > To unsubscribe from this topic, visit
>> > > https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> > > To unsubscribe from this group and all its topics, send an email to
>> > > [email protected].
>> > > To post to this group, send email to [email protected].
>> > > Visit this group at http://groups.google.com/group/modwsgi.
>> > > For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "modwsgi" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an
>> > email to [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at http://groups.google.com/group/modwsgi.
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "modwsgi" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/modwsgi/S1if2HhkGGE/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at http://groups.google.com/group/modwsgi.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/modwsgi.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/modwsgi.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/modwsgi.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/modwsgi.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.
