Re: URL lookup fails in apache/wsgi unless mapped to server root.
In case anyone else ends up with same problem, I was using request.path
instead of request.path_info.
P.
On Friday, 23 May 2014 14:58:11 UTC+10, Spaceman Paul wrote:
>
> Playing around some more, and inserting some trace statements in the
> django code, I can see
> (for the example ^times$ pattern):
>
> 1) When WSGIScriptAlias is the server root:
>
> The RegexURLResolver.resolve(self,path) method (in
> django.core.urlresolvers.py) is called three times,
> each time with path="/times" and each time it successfully resolves at the
> "^times$" pattern.
>
> 2) When WSGIScriptAlias is not server root (i.e. /awma):
>
> The RegexURLResolver.resolve(self,path) method (in
> django.core.urlresolvers.py) is called four times:
>
> a) The first two times it is called with path="/times" and successfully
> resolves at the "^times$" pattern.
> b) The third time it is called with path="/awma/times" - not surprisingly
> it does not resolve.
> c) The fourth time is is called with path="awma/times" - this fails too.
>
> It looks like the fourth call is made from within the third call - it's
> the call for the admin url include.
>
> Overall result is a 404.
>
> This is looking at the 2.4.13 codebase - although the method is basically
> the same in 2.6.5 and I
> see the same behaviour there.
>
> Is this a bug? Surely I can't be the only person using WSGI with a
> non-root mount point.
>
> P.
>
> On Friday, 23 May 2014 01:25:03 UTC+1, Spaceman Paul wrote:
>>
>> I've worked around it by creating another A-record and pointing each
>> application to the server root of the respective
>> virtual host, but this should not be necessary.
>>
>> On Thursday, 22 May 2014 23:50:57 UTC+1, Spaceman Paul wrote:
>>>
>>> Nothing in wsgi.conf.
>>>
>>> Relevant bits of apache conf:
>>>
>>>
>>>
>>> WSGIScriptAlias /awma
>>> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>>>
>>>
>>>
>>> Nothing in /var/log/apache2/error.log
>>>
>>> Access.log just says:
>>>
>>> 152.91.9.9 - - [23/May/2014:08:27:17 +1000] "GET /awma/ HTTP/1.1" 404
>>> 1476 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>> 152.91.9.9 - - [23/May/2014:08:27:22 +1000] "GET /awma/times HTTP/1.1"
>>> 404 1483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>>
>>> 404 debug pages like:
>>>
>>> Using the URLconf defined in internationalguidelines.urls, Django tried
>>> these URL patterns, in this order:
>>>
>>> 1. ^$ [name='index']
>>> 2. ^times$ [name='times']
>>> 3. ^admin/
>>>
>>> The current URL, times, didn't match any of these.
>>>
>>> AND: The current URL, , didn't match any of these
>>>
>>> Although weirdly, admin works:
>>>
>>> 152.91.9.9 - - [23/May/2014:08:28:19 +1000] "GET /awma/admin/ HTTP/1.1"
>>> 200 1450 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>>
>>> But when I change the WSGIScriptAlias to:
>>>
>>> WSGIScriptAlias /
>>> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>>>
>>> Everything works fine:
>>>
>>> 152.91.9.9 - - [23/May/2014:08:37:22 +1000] "GET / HTTP/1.1" 200 1156
>>> "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>> 152.91.9.9 - - [23/May/2014:08:37:27 +1000] "GET /times HTTP/1.1" 200
>>> 1550 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>> 152.91.9.9 - - [23/May/2014:08:37:39 +1000] "GET /admin/ HTTP/1.1" 200
>>> 1446 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>>
>>> WSGI file contains nothing unusual:
>>>
>>> import os
>>> import sys
>>>
>>> sys.path.append('/home/paul/src/awma-apache/')
>>> os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>>> "internationalguidelines.settings_prod")
>>>
>>> from django.core.wsgi import get_wsgi_application
>>> application = get_wsgi_application()
>>>
>>> I was trying to do some tricky stuff with virtualenv initially, but I
>>> still see the problem with the
>>> config stripped back very simple, as described above.
>>>
>>> P.
>>>
>>> On Thursday, 22 May 2014 21:29:02 UTC+1, WongoBongo wrote:
>>>>
>>>> Maybe post your apache.conf or/and your wsgi file. Maybe check your
>>>> Apache logs.
>>>>
>>>> K
>>>>
>>>> On Wednesday, May 21, 2014 11:01:29 PM UTC-7, Spaceman Paul wrote:
>>>>>
>>>>> No that's what I've got.
>>>>>
>>>>> P.
>>>>>
>>>>>
>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/f8014e30-aa3e-4b59-ba7e-6783f27802c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: URL lookup fails in apache/wsgi unless mapped to server root.
Ugh nevermind.
Yes it's a bug - but in my code. I'll figure it out.
On Friday, 23 May 2014 14:58:11 UTC+10, Spaceman Paul wrote:
>
> Playing around some more, and inserting some trace statements in the
> django code, I can see
> (for the example ^times$ pattern):
>
> 1) When WSGIScriptAlias is the server root:
>
> The RegexURLResolver.resolve(self,path) method (in
> django.core.urlresolvers.py) is called three times,
> each time with path="/times" and each time it successfully resolves at the
> "^times$" pattern.
>
> 2) When WSGIScriptAlias is not server root (i.e. /awma):
>
> The RegexURLResolver.resolve(self,path) method (in
> django.core.urlresolvers.py) is called four times:
>
> a) The first two times it is called with path="/times" and successfully
> resolves at the "^times$" pattern.
> b) The third time it is called with path="/awma/times" - not surprisingly
> it does not resolve.
> c) The fourth time is is called with path="awma/times" - this fails too.
>
> It looks like the fourth call is made from within the third call - it's
> the call for the admin url include.
>
> Overall result is a 404.
>
> This is looking at the 2.4.13 codebase - although the method is basically
> the same in 2.6.5 and I
> see the same behaviour there.
>
> Is this a bug? Surely I can't be the only person using WSGI with a
> non-root mount point.
>
> P.
>
> On Friday, 23 May 2014 01:25:03 UTC+1, Spaceman Paul wrote:
>>
>> I've worked around it by creating another A-record and pointing each
>> application to the server root of the respective
>> virtual host, but this should not be necessary.
>>
>> On Thursday, 22 May 2014 23:50:57 UTC+1, Spaceman Paul wrote:
>>>
>>> Nothing in wsgi.conf.
>>>
>>> Relevant bits of apache conf:
>>>
>>>
>>>
>>> WSGIScriptAlias /awma
>>> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>>>
>>>
>>>
>>> Nothing in /var/log/apache2/error.log
>>>
>>> Access.log just says:
>>>
>>> 152.91.9.9 - - [23/May/2014:08:27:17 +1000] "GET /awma/ HTTP/1.1" 404
>>> 1476 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>> 152.91.9.9 - - [23/May/2014:08:27:22 +1000] "GET /awma/times HTTP/1.1"
>>> 404 1483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>>
>>> 404 debug pages like:
>>>
>>> Using the URLconf defined in internationalguidelines.urls, Django tried
>>> these URL patterns, in this order:
>>>
>>> 1. ^$ [name='index']
>>> 2. ^times$ [name='times']
>>> 3. ^admin/
>>>
>>> The current URL, times, didn't match any of these.
>>>
>>> AND: The current URL, , didn't match any of these
>>>
>>> Although weirdly, admin works:
>>>
>>> 152.91.9.9 - - [23/May/2014:08:28:19 +1000] "GET /awma/admin/ HTTP/1.1"
>>> 200 1450 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>>
>>> But when I change the WSGIScriptAlias to:
>>>
>>> WSGIScriptAlias /
>>> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>>>
>>> Everything works fine:
>>>
>>> 152.91.9.9 - - [23/May/2014:08:37:22 +1000] "GET / HTTP/1.1" 200 1156
>>> "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>> 152.91.9.9 - - [23/May/2014:08:37:27 +1000] "GET /times HTTP/1.1" 200
>>> 1550 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>> 152.91.9.9 - - [23/May/2014:08:37:39 +1000] "GET /admin/ HTTP/1.1" 200
>>> 1446 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>>> Firefox/29.0"
>>>
>>> WSGI file contains nothing unusual:
>>>
>>> import os
>>> import sys
>>>
>>> sys.path.append('/home/paul/src/awma-apache/')
>>> os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>>> "internationalguidelines.settings_prod")
>>>
>>> from django.core.wsgi import get_wsgi_application
>>> application = get_wsgi_application()
>>>
>>> I was trying to do some tricky stuff with virtualenv initially, but I
>>> still see the problem with the
>>> config stripped back very simple, as described above.
>>>
>>> P.
>>>
>>> On Thursday, 22 May 2014 21:29:02 UTC+1, WongoBongo wrote:
>>>>
>>>> Maybe post your apache.conf or/and your wsgi file. Maybe check your
>>>> Apache logs.
>>>>
>>>> K
>>>>
>>>> On Wednesday, May 21, 2014 11:01:29 PM UTC-7, Spaceman Paul wrote:
>>>>>
>>>>> No that's what I've got.
>>>>>
>>>>> P.
>>>>>
>>>>>
>>>>>>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/486eb942-7e6f-4c79-8dc0-fee7ee91e272%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: URL lookup fails in apache/wsgi unless mapped to server root.
Playing around some more, and inserting some trace statements in the django
code, I can see
(for the example ^times$ pattern):
1) When WSGIScriptAlias is the server root:
The RegexURLResolver.resolve(self,path) method (in
django.core.urlresolvers.py) is called three times,
each time with path="/times" and each time it successfully resolves at the
"^times$" pattern.
2) When WSGIScriptAlias is not server root (i.e. /awma):
The RegexURLResolver.resolve(self,path) method (in
django.core.urlresolvers.py) is called four times:
a) The first two times it is called with path="/times" and successfully
resolves at the "^times$" pattern.
b) The third time it is called with path="/awma/times" - not surprisingly
it does not resolve.
c) The fourth time is is called with path="awma/times" - this fails too.
It looks like the fourth call is made from within the third call - it's the
call for the admin url include.
Overall result is a 404.
This is looking at the 2.4.13 codebase - although the method is basically
the same in 2.6.5 and I
see the same behaviour there.
Is this a bug? Surely I can't be the only person using WSGI with a
non-root mount point.
P.
On Friday, 23 May 2014 01:25:03 UTC+1, Spaceman Paul wrote:
>
> I've worked around it by creating another A-record and pointing each
> application to the server root of the respective
> virtual host, but this should not be necessary.
>
> On Thursday, 22 May 2014 23:50:57 UTC+1, Spaceman Paul wrote:
>>
>> Nothing in wsgi.conf.
>>
>> Relevant bits of apache conf:
>>
>>
>>
>> WSGIScriptAlias /awma
>> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>>
>>
>>
>> Nothing in /var/log/apache2/error.log
>>
>> Access.log just says:
>>
>> 152.91.9.9 - - [23/May/2014:08:27:17 +1000] "GET /awma/ HTTP/1.1" 404
>> 1476 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>> Firefox/29.0"
>> 152.91.9.9 - - [23/May/2014:08:27:22 +1000] "GET /awma/times HTTP/1.1"
>> 404 1483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>> Firefox/29.0"
>>
>> 404 debug pages like:
>>
>> Using the URLconf defined in internationalguidelines.urls, Django tried
>> these URL patterns, in this order:
>>
>> 1. ^$ [name='index']
>> 2. ^times$ [name='times']
>> 3. ^admin/
>>
>> The current URL, times, didn't match any of these.
>>
>> AND: The current URL, , didn't match any of these
>>
>> Although weirdly, admin works:
>>
>> 152.91.9.9 - - [23/May/2014:08:28:19 +1000] "GET /awma/admin/ HTTP/1.1"
>> 200 1450 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>> Firefox/29.0"
>>
>> But when I change the WSGIScriptAlias to:
>>
>> WSGIScriptAlias /
>> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>>
>> Everything works fine:
>>
>> 152.91.9.9 - - [23/May/2014:08:37:22 +1000] "GET / HTTP/1.1" 200 1156 "-"
>> "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
>> 152.91.9.9 - - [23/May/2014:08:37:27 +1000] "GET /times HTTP/1.1" 200
>> 1550 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>> Firefox/29.0"
>> 152.91.9.9 - - [23/May/2014:08:37:39 +1000] "GET /admin/ HTTP/1.1" 200
>> 1446 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
>> Firefox/29.0"
>>
>> WSGI file contains nothing unusual:
>>
>> import os
>> import sys
>>
>> sys.path.append('/home/paul/src/awma-apache/')
>> os.environ.setdefault("DJANGO_SETTINGS_MODULE",
>> "internationalguidelines.settings_prod")
>>
>> from django.core.wsgi import get_wsgi_application
>> application = get_wsgi_application()
>>
>> I was trying to do some tricky stuff with virtualenv initially, but I
>> still see the problem with the
>> config stripped back very simple, as described above.
>>
>> P.
>>
>> On Thursday, 22 May 2014 21:29:02 UTC+1, WongoBongo wrote:
>>>
>>> Maybe post your apache.conf or/and your wsgi file. Maybe check your
>>> Apache logs.
>>>
>>> K
>>>
>>> On Wednesday, May 21, 2014 11:01:29 PM UTC-7, Spaceman Paul wrote:
>>>>
>>>> No that's what I've got.
>>>>
>>>> P.
>>>>
>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/2dbf12c9-6da7-4162-b90e-38c99c62d977%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: URL lookup fails in apache/wsgi unless mapped to server root.
I've worked around it by creating another A-record and pointing each
application to the server root of the respective
virtual host, but this should not be necessary.
On Thursday, 22 May 2014 23:50:57 UTC+1, Spaceman Paul wrote:
>
> Nothing in wsgi.conf.
>
> Relevant bits of apache conf:
>
>
>
> WSGIScriptAlias /awma
> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>
>
>
> Nothing in /var/log/apache2/error.log
>
> Access.log just says:
>
> 152.91.9.9 - - [23/May/2014:08:27:17 +1000] "GET /awma/ HTTP/1.1" 404 1476
> "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Firefox/29.0"
> 152.91.9.9 - - [23/May/2014:08:27:22 +1000] "GET /awma/times HTTP/1.1" 404
> 1483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Firefox/29.0"
>
> 404 debug pages like:
>
> Using the URLconf defined in internationalguidelines.urls, Django tried
> these URL patterns, in this order:
>
> 1. ^$ [name='index']
> 2. ^times$ [name='times']
> 3. ^admin/
>
> The current URL, times, didn't match any of these.
>
> AND: The current URL, , didn't match any of these
>
> Although weirdly, admin works:
>
> 152.91.9.9 - - [23/May/2014:08:28:19 +1000] "GET /awma/admin/ HTTP/1.1"
> 200 1450 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Firefox/29.0"
>
> But when I change the WSGIScriptAlias to:
>
> WSGIScriptAlias /
> /home/paul/src/awma-apache/internationalguidelines/wsgi.py
>
> Everything works fine:
>
> 152.91.9.9 - - [23/May/2014:08:37:22 +1000] "GET / HTTP/1.1" 200 1156 "-"
> "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
> 152.91.9.9 - - [23/May/2014:08:37:27 +1000] "GET /times HTTP/1.1" 200 1550
> "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Firefox/29.0"
> 152.91.9.9 - - [23/May/2014:08:37:39 +1000] "GET /admin/ HTTP/1.1" 200
> 1446 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
> Firefox/29.0"
>
> WSGI file contains nothing unusual:
>
> import os
> import sys
>
> sys.path.append('/home/paul/src/awma-apache/')
> os.environ.setdefault("DJANGO_SETTINGS_MODULE",
> "internationalguidelines.settings_prod")
>
> from django.core.wsgi import get_wsgi_application
> application = get_wsgi_application()
>
> I was trying to do some tricky stuff with virtualenv initially, but I
> still see the problem with the
> config stripped back very simple, as described above.
>
> P.
>
> On Thursday, 22 May 2014 21:29:02 UTC+1, WongoBongo wrote:
>>
>> Maybe post your apache.conf or/and your wsgi file. Maybe check your
>> Apache logs.
>>
>> K
>>
>> On Wednesday, May 21, 2014 11:01:29 PM UTC-7, Spaceman Paul wrote:
>>>
>>> No that's what I've got.
>>>
>>> P.
>>>
>>>
>>>>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/775fc3eb-e0b2-470d-afef-f84d2657f9a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: URL lookup fails in apache/wsgi unless mapped to server root.
Nothing in wsgi.conf.
Relevant bits of apache conf:
WSGIScriptAlias /awma
/home/paul/src/awma-apache/internationalguidelines/wsgi.py
Nothing in /var/log/apache2/error.log
Access.log just says:
152.91.9.9 - - [23/May/2014:08:27:17 +1000] "GET /awma/ HTTP/1.1" 404 1476
"-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
Firefox/29.0"
152.91.9.9 - - [23/May/2014:08:27:22 +1000] "GET /awma/times HTTP/1.1" 404
1483 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
Firefox/29.0"
404 debug pages like:
Using the URLconf defined in internationalguidelines.urls, Django tried
these URL patterns, in this order:
1. ^$ [name='index']
2. ^times$ [name='times']
3. ^admin/
The current URL, times, didn't match any of these.
AND: The current URL, , didn't match any of these
Although weirdly, admin works:
152.91.9.9 - - [23/May/2014:08:28:19 +1000] "GET /awma/admin/ HTTP/1.1" 200
1450 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
Firefox/29.0"
But when I change the WSGIScriptAlias to:
WSGIScriptAlias /
/home/paul/src/awma-apache/internationalguidelines/wsgi.py
Everything works fine:
152.91.9.9 - - [23/May/2014:08:37:22 +1000] "GET / HTTP/1.1" 200 1156 "-"
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0"
152.91.9.9 - - [23/May/2014:08:37:27 +1000] "GET /times HTTP/1.1" 200 1550
"-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
Firefox/29.0"
152.91.9.9 - - [23/May/2014:08:37:39 +1000] "GET /admin/ HTTP/1.1" 200 1446
"-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101
Firefox/29.0"
WSGI file contains nothing unusual:
import os
import sys
sys.path.append('/home/paul/src/awma-apache/')
os.environ.setdefault("DJANGO_SETTINGS_MODULE",
"internationalguidelines.settings_prod")
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
I was trying to do some tricky stuff with virtualenv initially, but I still
see the problem with the
config stripped back very simple, as described above.
P.
On Thursday, 22 May 2014 21:29:02 UTC+1, WongoBongo wrote:
>
> Maybe post your apache.conf or/and your wsgi file. Maybe check your Apache
> logs.
>
> K
>
> On Wednesday, May 21, 2014 11:01:29 PM UTC-7, Spaceman Paul wrote:
>>
>> No that's what I've got.
>>
>> P.
>>
>>
>>>>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/1365b1ed-3d65-4f99-b9ba-f98fa5aaf82e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: URL lookup fails in apache/wsgi unless mapped to server root.
No that's what I've got. P. On Thursday, 22 May 2014 15:14:01 UTC+10, WongoBongo wrote: > > Maybe > > WSGIScriptAlias /awma /var/www/djangoapp/djangoapp/wsgi.py > > K > > On Wednesday, May 21, 2014 9:27:14 PM UTC-7, Spaceman Paul wrote: >> >> My application works fine in runserver and in apache/wsgi mapped to root, >> but when I map wsgi to a directory, url lookups fail. >> >> E.g. >> >> Request URL: http://server/awma/times >> ... >> ^times$ [name='times'] >> ... >> The current URL, times, didn't match any of these. >> >> Every single URL in the (full) list fails (including "^$", but weirdly >> enough /admin works fine). >> >> Again, I stress that this all works fine in runserver, and if >> WSGIScriptAlias is mapped to the server root. >> >> I cannot make sense of this as the URL getting passed to the URL resolver >> is correct and should match. >> >> Any suggestions? >> >> Python 2.7. >> Django 1.6.5, but I see the same behaviour with Django 1.4.13. >> >> P. >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/849efc6e-2bd7-47f0-affb-ed983938f038%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
URL lookup fails in apache/wsgi unless mapped to server root.
My application works fine in runserver and in apache/wsgi mapped to root, but when I map wsgi to a directory, url lookups fail. E.g. Request URL: http://server/awma/times ... ^times$ [name='times'] ... The current URL, times, didn't match any of these. Every single URL in the (full) list fails (including "^$", but weirdly enough /admin works fine). Again, I stress that this all works fine in runserver, and if WSGIScriptAlias is mapped to the server root. I cannot make sense of this as the URL getting passed to the URL resolver is correct and should match. Any suggestions? Python 2.7. Django 1.6.5, but I see the same behaviour with Django 1.4.13. P. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fb7d17d5-a530-4ea6-9d03-23d9d00b78e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
XSD from a Django model (as per XML serializer)
Is there a way to generate an XSD for the "simple xml dialect" produced by the XML serializer for a given Django model? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: CSRF protection in admin in Django 1.2
Seems to only be a problem when my over-ridden view function calls
down to the base class view implementation. And indeed an excessive
exercise in copy-and-pasting fixes it.
It would be nice if there was a clean simple way to turn CSRF off in
sub-classed
admin sites. E.g:
class MyAdminSite(AdminSite):
csrf_protection = False
I guess I'll open a ticket for it.
Paul.
On May 18, 10:47 am, Spaceman Paul <linkjugg...@gmail.com> wrote:
> Hi, I just upgraded to Django 1.2 and am having some problems.
>
> My project contains several customised django.contrib.admin sites that
> offer highly stripped down subsets of admin functionality. These
> customised sites do not use authentication and are expected to be
> POSTed to both by users and by external applications. This new cross-
> site request forgery protection magic therefore severely gets in the
> way.
>
> Is there a quick/simple way to turn CSRF protection off for these
> AdminSite subclasses? I've tried decorating my (already over-ridden
> views) with "csrf_exempt" and am already over-riding the templates
> with ones that don't have a {% csrf_token %} tag, but I'm still
> getting CSRF 403 errors.
>
> Regards,
>
> Paul.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group
> athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
CSRF protection in admin in Django 1.2
Hi, I just upgraded to Django 1.2 and am having some problems.
My project contains several customised django.contrib.admin sites that
offer highly stripped down subsets of admin functionality. These
customised sites do not use authentication and are expected to be
POSTed to both by users and by external applications. This new cross-
site request forgery protection magic therefore severely gets in the
way.
Is there a quick/simple way to turn CSRF protection off for these
AdminSite subclasses? I've tried decorating my (already over-ridden
views) with "csrf_exempt" and am already over-riding the templates
with ones that don't have a {% csrf_token %} tag, but I'm still
getting CSRF 403 errors.
Regards,
Paul.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Nesting model forms with admin
I can't find the ticket, Matt. If you could forward me a link, or
just
dig that patch up for me, I'd greatly appreciate it.
Paul.
On May 2, 8:41 pm, Matt Schinckel <m...@schinckel.net> wrote:
> I have a patch: it was a while ago, but I was about to dig it up
> again.
>
> In the meantime, there is an open ticket - I think my patch is
> attached.
>
> Matt
>
> On Apr 20, 10:49 am, Spaceman Paul <linkjugg...@gmail.com> wrote:
>
>
>
> > I'm looking at extending the django admin app for a project, as it
> > does about 96% of what we need straight out of the box. The main
> > feature not offered is what might be called nested modelforms.
>
> > Stretching the example from the InlineModelAdmin documentation (which
> > does almost the exact opposite of what I want), suppose we have the
> > following models:
>
> > class Author(models.Model):
> > name = models.CharField(max_length=100)
>
> > class Book(models.Model):
> > author = models.ForeignKey(Author)
> > title = models.CharField(max_length=100)
>
> > Suppose also that I don't want to reuse Authors between books. In
> > this trivial example, I would simply merge the Author field into the
> > Book Model:
>
> > class Book(models.Model):
> > author = models.ForeignKey(Author)
> > title = models.CharField(max_length=100)
> > author_name = models.CharField(max_length=100)
>
> > But in a more complex situation, I might want to keep the Author
> > fields in a separate table either simply for organisational reasons,
> > or because a Book might have multiple types of Authors:
>
> > class Book(models.Model):
> > original_author = models.ForeignKey(Author)
> > abridging_author = models.ForeignKey(Author)
> > translating_author = models.ForeignKey(Author)
> > title = models.CharField(max_length=100)
>
> > But still, I want to be able to make all fields to appear in a single
> > admin form per book, without a separate view for handling authors. I
> > picture it as working something like this:
>
> > class AuthorAdmin(admin.NestedModelAdmin):
> > pass
>
> > class BookAdmin(admin.ModelAdmin):
> > nested_forms = [ ('original_author', AuthorAdmin),
> > ('abridging_author', AuthorAdmin),
> > ('translating_author', AuthorAdmin),
> > ]
> > admin.site.register(Book, BookAdmin)
>
> > My questions:
>
> > 1) Is there some feature in the admin application that already does
> > this that I have overlooked?
> > 2) Does anybody already have a patch that does something similar?
>
> > Assuming the answer to both the above is "no", I'm prepared to dive in
> > and implement it myself (the admin code looks reasonably clean and
> > well structured). Assuming I do implement it myself:
>
> > 3) Are there any subtle gotchas in the admin code I should be aware of
> > before I start?
> > 4) Any suggestions of more elegant designs would be appreciated.
> > 5) Is there anybody else in Django land who would be interested in
> > this sort of functionality? Would the admin maintainers have any
> > technical or ideological reasons for rejecting a patch to implement
> > this if I submitted one?
>
> > Regards,
>
> > Paul.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group
> athttp://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Nesting model forms with admin
I'm looking at extending the django admin app for a project, as it
does about 96% of what we need straight out of the box. The main
feature not offered is what might be called nested modelforms.
Stretching the example from the InlineModelAdmin documentation (which
does almost the exact opposite of what I want), suppose we have the
following models:
class Author(models.Model):
name = models.CharField(max_length=100)
class Book(models.Model):
author = models.ForeignKey(Author)
title = models.CharField(max_length=100)
Suppose also that I don't want to reuse Authors between books. In
this trivial example, I would simply merge the Author field into the
Book Model:
class Book(models.Model):
author = models.ForeignKey(Author)
title = models.CharField(max_length=100)
author_name = models.CharField(max_length=100)
But in a more complex situation, I might want to keep the Author
fields in a separate table either simply for organisational reasons,
or because a Book might have multiple types of Authors:
class Book(models.Model):
original_author = models.ForeignKey(Author)
abridging_author = models.ForeignKey(Author)
translating_author = models.ForeignKey(Author)
title = models.CharField(max_length=100)
But still, I want to be able to make all fields to appear in a single
admin form per book, without a separate view for handling authors. I
picture it as working something like this:
class AuthorAdmin(admin.NestedModelAdmin):
pass
class BookAdmin(admin.ModelAdmin):
nested_forms = [ ('original_author', AuthorAdmin),
('abridging_author', AuthorAdmin),
('translating_author', AuthorAdmin),
]
admin.site.register(Book, BookAdmin)
My questions:
1) Is there some feature in the admin application that already does
this that I have overlooked?
2) Does anybody already have a patch that does something similar?
Assuming the answer to both the above is "no", I'm prepared to dive in
and implement it myself (the admin code looks reasonably clean and
well structured). Assuming I do implement it myself:
3) Are there any subtle gotchas in the admin code I should be aware of
before I start?
4) Any suggestions of more elegant designs would be appreciated.
5) Is there anybody else in Django land who would be interested in
this sort of functionality? Would the admin maintainers have any
technical or ideological reasons for rejecting a patch to implement
this if I submitted one?
Regards,
Paul.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
