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.
