What I gave you was intended just to try and help you verify what the issue is,
but be aware that --https-only is not working as intended in the typical case
and is not forcing a HTTP request to be a HTTPS request. It only works if you
also have used the --server-alias option.
I have a fix for the next version of mod_wsgi.
If there was some reason you really needed it for now, then add --server-alias
with a dummy value.
--server-alias dummy.redacted
Graham
On 18/12/2014, at 7:39 AM, Graham Dumpleton <[email protected]> wrote:
> Whoops. Should have been --working-directory instead of --home.
>
> Graham
>
> On 18/12/2014, at 6:35 AM, Jennifer Mehl <[email protected]> wrote:
>
>> I gave this mod_wsgi-express a try, but it is spitting out an error about
>> the —home option not being a valid option. What should I be using instead?
>>
>> thanks,
>> Jennifer
>>
>>> On Dec 16, 2014, at 9:32 PM, Graham Dumpleton <[email protected]>
>>> wrote:
>>>
>>> One question. Is:
>>>
>>> SSLCertificateFile /etc/ssl/certs/***
>>> SSLCertificateKeyFile /etc/ssl/private/**
>>> SSLCertificateChainFile /etc/ssl/certs/**
>>> SSLCipherSuite HIGH:!aNULL:!MD5
>>>
>>> what you actually have in the Apache configuration, including the '**', or
>>> did you do that to mask information.
>>>
>>> SSL configurations I have seen don't tend to have SSLCertificateChainFile
>>> either. Not sure if that is a requirement for you or not.
>>>
>>> Generally I just use:
>>>
>>> SLCertificateFile server.crt
>>> SSLCertificateKeyFile server.key
>>>
>>> I am always using self signed certificate files though.
>>>
>>> Anyway, if you are happy with trying radical solutions, or at least
>>> validating Apache/mod_wsgi with SSL works with a configuration done by
>>> someone else, I have this dead horse called 'pip' I have been trying to
>>> sell with not much luck.
>>>
>>> Seriously, for a perhaps quick way of testing an alternate SSL
>>> configuration with Apache, try this:
>>>
>>> pip install mod_wsgi
>>>
>>> sudo mod_wsgi-express start-server --user mod_wsgi --group mod_wsgi --port
>>> 80 --ssl-port 443 \
>>> --ssl-certificate server --https-only --server-name redacted --home
>>> /var/www/transfergateway \
>>> --url-alias /media /var/www/transfergateway/myproject/myapp/media \
>>> --url-alias /static /var/www/transfergateway/myproject/myapp/static \
>>> /var/www/transfergateway/myproject/apache/wsgi.py
>>>
>>> You would need to stop the existing Apache first. Change 'redacted' to the
>>> actual ServerName value. The user and group to actual names for them. And
>>> have the SSL server.cert and server.key files together in the same
>>> directory and change 'server' argument to --ssl-certificate to be path to
>>> directory they are in, with the common base name part of the files on the
>>> end. That is, with extensions dropped off.
>>>
>>> Okay, maybe too radical, but believe it or not that command line should
>>> hopefully run up Apache/mod_wsgi against your Django site if I got all the
>>> arguments right, with HTTPS all setup and in a HTTPS only configuration
>>> such that access to HTTP will redirect automatically to HTTPS URLs.
>>>
>>> Worth a try I guess if you really get stuck. :-)
>>>
>>> Graham
>>>
>>> On 17/12/2014, at 3: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�0
>>>>>>>
>>>>>>> #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% 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 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.
