On 17 July 2012 11:24, DougE <[email protected]> wrote: > For the record, I was unable to get Apache to accept 'Deny' in that context.
Try instead: <VirtualHost _default_:*> <Location /> Deny from all </Location> </VirtualHost> But your description does sound like it may have been falling back to the first VirtualHost after not matching the others properly. Graham > I think my httpd.conf was problematic because although main server was bound > to 127.0.0.1:8080, my virtual server was defined with *:8080. > > Also, by accident I discovered that although the /moin suburl was called > with the https: scheme on the page, I could successfully ask my browser to > go to http://mydomain/moin and this not only was successful; it broke > things. > > By specifying my virtual server as 127.0.0.1:8080 and rewriting the > http://.../moin to https://... everything seems to be working . > > Given the nature of this anomaly, port 80 and https served with http and > inability to specify _default_ virtualhost, can anyone see any un-addressed > vulnerability? > > > > On Tuesday, July 17, 2012 2:36:01 AM UTC-4, Graham Dumpleton wrote: >> >> A little bit more detail. >> >> If you have a site on 8080 and something connects on that port, but >> the Host header doesn't match properly the ServerName/ServerAlias, >> Apache will fallback to using the very first VirtualHost it found when >> parsing the configuration files. This means the request would be >> served in that case by port 80 VirtualHost definition. >> >> Best practice would be to define a _default_ VirtualHost for port 80 >> as very first one Apache finds: >> >> <VirtualHost _default_:*> >> Deny from all >> </VirtualHost> >> >> So, if something goes wrong with virtual host, will be refused. See: >> >> http://httpd.apache.org/docs/2.2/vhosts/examples.html#default >> >> See if when you do that you get a forbidden indicating that host >> mapping wasn't find a match. >> >> Graham >> >> On 16 July 2012 18:39, DougE <[email protected]> wrote: >> > Graham -- >> > >> > That seems to have cleared it up. I was wondering why the default >> > WSGIApplicationGroup %{RESOURCE} did not do the trick, so yeah, some >> > background would be good, not at all urgent, when you have time. >> > >> > Once again, Graham, thanks. >> > >> > >> > On Monday, July 16, 2012 9:23:32 PM UTC-4, Graham Dumpleton wrote: >> >> >> >> If only web application in that daemon process group, force >> >> WSGIApplicationGroup to %{GLOBAL}. >> >> >> >> That will avoid two copies of application. I'll explain properly later. >> >> >> >> Graham >> >> >> >> On 16/07/2012, at 5:34 PM, DougE <[email protected]> wrote: >> >> >> >> Well, it works -- kind of. Django is sending me some emails about this >> >> strange side effect. It is strange because Apache is looking at the >> >> wrong >> >> wsgi ap, and it should never be looking at port 80 since I have it >> >> bound to >> >> 8080. Here is what django is telling me after calling the wsgi scrip >> >> on the >> >> /moin suburl: >> >> >> >> Traceback (most recent call last): >> >> >> >> File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", >> >> line 150, in get_response >> >> response = callback(request, **param_dict) >> >> >> >> File "/usr/lib/python2.7/site-packages/django/utils/decorators.py", >> >> line >> >> 93, in _wrapped_view >> >> response = view_func(request, *args, **kwargs) >> >> >> >> File "/usr/lib/python2.7/site-packages/django/views/defaults.py", >> >> line >> >> 18, in page_not_found >> >> t = loader.get_template(template_name) # You need to create a >> >> 404.html >> >> template. >> >> >> >> File "/usr/lib/python2.7/site-packages/django/template/loader.py", >> >> line >> >> 157, in get_template >> >> template, origin = find_template(template_name) >> >> >> >> File "/usr/lib/python2.7/site-packages/django/template/loader.py", >> >> line >> >> 138, in find_template >> >> raise TemplateDoesNotExist(name) >> >> >> >> TemplateDoesNotExist: 404.html >> >> >> >> >> >> <WSGIRequest >> >> GET:<QueryDict: {}>, >> >> POST:<QueryDict: {}>, >> >> COOKIES:{}, >> >> """CSRF is a django artifact, don't really understand why it is here""" >> >> META:{'CSRF_COOKIE': '41bd340808e6201039389f5b379293b1', >> >> """Don't know where the following path is coming from""" >> >> 'DOCUMENT_ROOT': '/etc/httpd/htdocs', >> >> 'GATEWAY_INTERFACE': 'CGI/1.1', >> >> 'HTTPS': 'on', >> >> 'HTTP_ACCEPT': 'image/png,image/*;q=0.8,*/*;q=0.5', >> >> 'HTTP_ACCEPT_ENCODING': 'gzip, deflate', >> >> 'HTTP_ACCEPT_LANGUAGE': 'en-us,en;q=0.5', >> >> 'HTTP_CONNECTION': 'close', >> >> 'HTTP_DNT': '1', >> >> 'HTTP_HOST': 'mydomain.com', >> >> 'HTTP_USER_AGENT': 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) >> >> Gecko/20100101 Firefox/13.0.1', >> >> 'HTTP_X_FORWARDED_PROTOCOL': 'https', >> >> 'HTTP_X_FORWRDED_FOR': '98.23.50.238', >> >> 'HTTP_X_REAL_IP': '98.23.50.238', >> >> """don't know where following is referenced although it looks like >> >> something from moin""" >> >> 'PATH_INFO': u'/favicon.ico', >> >> 'PATH_TRANSLATED': >> >> '/directory_to/django_app/not_moin/wsgi_handler.py/favicon.ico', >> >> 'QUERY_STRING': '', >> >> 'REMOTE_ADDR': '127.0.0.1', >> >> 'REMOTE_PORT': '56932', >> >> 'REQUEST_METHOD': 'GET', >> >> 'REQUEST_URI': '/favicon.ico', >> >> 'SCRIPT_FILENAME': >> >> '/directory_to/django_app/not_moin/wsgi_handler.py', >> >> 'SCRIPT_NAME': u'', >> >> 'SERVER_ADDR': '127.0.0.1', >> >> 'SERVER_ADMIN': 'root@localhost', >> >> 'SERVER_NAME': 'mydomain.com', >> >> """Port 80 should never be happening""" >> >> 'SERVER_PORT': '80', >> >> 'SERVER_PROTOCOL': 'HTTP/1.0', >> >> 'SERVER_SIGNATURE': '<address>Apache/2.2.17 (Fedora) Server at >> >> mydomain.com Port 80</address>\n', >> >> 'SERVER_SOFTWARE': 'Apache/2.2.17 (Fedora)', >> >> 'mod_wsgi.application_group': 'mydomain|', >> >> 'mod_wsgi.callable_object': 'application', >> >> 'mod_wsgi.handler_script': '', >> >> 'mod_wsgi.input_chunked': '0', >> >> 'mod_wsgi.listener_host': '127.0.0.1', >> >> 'mod_wsgi.listener_port': '8080', >> >> 'mod_wsgi.process_group': 'mydomain', >> >> 'mod_wsgi.request_handler': 'wsgi-script', >> >> 'mod_wsgi.script_reloading': '1', >> >> 'mod_wsgi.version': (3, 2), >> >> 'wsgi.errors': <mod_wsgi.Log object at 0x7f3e8ca1c730>, >> >> 'wsgi.file_wrapper': <built-in method file_wrapper of mod_wsgi.Adapter >> >> object at 0x7f3e8ca06378>, >> >> 'wsgi.input': <mod_wsgi.Input object at 0x7f3e8c9c3ef0>, >> >> 'wsgi.multiprocess': False, >> >> 'wsgi.multithread': True, >> >> 'wsgi.run_once': False, >> >> 'wsgi.url_scheme': 'https', >> >> 'wsgi.version': (1, 1)}> >> >> >> >> On Saturday, July 14, 2012 7:56:49 PM UTC-4, Graham Dumpleton wrote: >> >>> >> >>> Yes you can have more than one WSGIScriptAlias. The order is important >> >>> though. Have that for the sub URL before that for root of '/'. >> >>> >> >>> WSGIScriptAlias /suburl /some/path/app1.wsgi >> >>> WSGIScriptAlias / /some/path/app2.wsgi >> >>> >> >>> Can you post the actual configuration snippet you are using rather >> >>> than refer to an old post as can only assume that you are actually >> >>> entering it in correct? >> >>> >> >>> Graham >> >>> >> >>> On 12 July 2012 22:52, DougE <[email protected]> wrote: >> >>> > Sorry to bother -- I have done this: setup and I have spent a week >> >>> > breaking >> >>> > it by trying to add moin on this site as a sub url. I was trying >> >>> > two >> >>> > <virtualhost>'s based on different ports, no luck. >> >>> > >> >>> > Can a single <virtualhost> tag contain more than one WSGIScriptAlias >> >>> > directive? >> >>> > >> >>> > Can someone provide guidance on best way to call two completely >> >>> > different >> >>> > wsgi scripts from Apache? >> >>> > >> >>> > >> >>> > -- >> >>> > You received this message because you are subscribed to the Google >> >>> > Groups >> >>> > "modwsgi" group. >> >>> > To view this discussion on the web visit >> >>> > https://groups.google.com/d/msg/modwsgi/-/FvtkKpOlu9gJ. >> >>> > To post to this group, send email to [email protected]. >> >>> > To unsubscribe from this group, send email to >> >>> > [email protected]. >> >>> > For more options, visit this group at >> >>> > http://groups.google.com/group/modwsgi?hl=en. >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "modwsgi" group. >> >> To view this discussion on the web visit >> >> https://groups.google.com/d/msg/modwsgi/-/vPRlg3namnoJ. >> >> To post to this group, send email to [email protected]. >> >> To unsubscribe from this group, send email to >> >> [email protected]. >> >> For more options, visit this group at >> >> http://groups.google.com/group/modwsgi?hl=en. >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "modwsgi" group. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msg/modwsgi/-/VpWCLnZSXlkJ. >> > >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group at >> > http://groups.google.com/group/modwsgi?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/modwsgi/-/IZQNo7dO2A4J. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
