Re: scripted login to django
On 23/02/2011 11:51, Mike Ramirez wrote:
...
Have your tried urllib2.Request[1] to POST your login data, how a browser
would do it?
yes
...
eventually I got this to work with 1.2.5 (and the tutorial site); the main
problems were that hitting admin to get the csrfmiddlewaretoken pops up a login
page which posts back to /admin/ (not /admin/login/); also it seems we need to
add in the extra hidden variable this_is_the_login_form to make things work better.
import urllib2, urllib, cookielib
site='http://127.0.0.1:8000'
cj = cookielib.CookieJar()
# build opener with HTTPCookieProcessor
o = urllib2.build_opener( urllib2.HTTPCookieProcessor(cj))
urllib2.install_opener( o )
print 1, 30*'='
for cookie in cj:
print cookie.domain, cookie.path, cookie.name, cookie.value
# perform login with params
f = o.open( site + '/admin/')
data = f.read()
f.close()
print 1,30*'!'
print data
D={ 'username': 'myuser', 'password': 'mypassword', 'this_is_the_login_form':
'1'}
tl = [l for l in data.split('\n') if 'csrfmiddlewaretoken' in l]
if not tl:
raise ValueError('no csrf token found')
tl = tl[0].split('value=')
tl = tl[1].split(' ')[0].strip('"\'')
D['csrfmiddlewaretoken'] = tl
p = urllib.urlencode(D)
print 2, 30*'='
for cookie in cj:
print cookie.domain, cookie.path, cookie.name, cookie.value
f = o.open( site + '/admin/',p)
data = f.read()
f.close()
print 2,30*'!'
print data
# second request should automatically pass back any
# cookies received during login... thanks to the HTTPCookieProcessor
print 3, 30*'='
for cookie in cj:
print cookie.domain, cookie.path, cookie.name, cookie.value
f = o.open( site+'/admin/')
data = f.read()
f.close()
print 3,30*'!'
print data
--
Robin Becker
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@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.
scripted login to django
I want to automate a remote django view which requires a login with a python script, but I am having difficulty in deciding how to make django accept the various cookies. Is there example code somewhere which shows how this should be done? I've tried various cookie jar based approaches, but they don't seem to work. The test client works through the server code rather than through the web. -- Robin Becker -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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.
weird template escaping
Hi, I have a custom Form that's attempting to expand the following
field.label=u'Elegant, sophisticated, discover Egypt\u2019s local customs'
in a template. The template code looks like
{{ field.label }}
using some special debugging tricks I can determine that, immediately prior to
the expansion, the field.label value is still in unicode and has the right value.
However, when the expansion takes place I see the following in the output html
Elegant, sophisticated, discover Egyptâ€s local customs
so it looks as though something is being silly and doing the following
1) translate to utf8 ie 'Elegant, sophisticated, discover Egypt\xe2\x80\x99s
local customs'
2) escaping \x99 as (trademark char is == )
where should I start looking to locate the problem?
--
Robin Becker
--
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.
apache authentication with django+flip+fastcgi
We currently have django(using flup) running as a fastcgi external server (via a socket) and would like to use django to control access to static apache files (to avoid duplicate logins etc etc); I see that fastcgi can do Authentication (in the http sense) and access checking. Is there a way to get django to control static access in this manner. I know that I can start up a secondary version of my project and use it as a standalone fastcgi script to do what I need, but that requires me to control two servers when changes are made and seems a bit clunky. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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 -~--~~~~--~~--~--~---
field media api
I'm having some troubles working out how to control the order in which javascript resources are rendered. If I have two fields A & B which have dynamic media properties is there a way to inspect the combined media prior to rendering. I seem to be getting both lists of js files without any attempt at sorting so I end up with some files included twice etc etc. Is there a way to hook the final rendering? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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: multiple projects shared database
derek wrote: > >>> On the other hand, if the two websites are entirely independent, putting >>> them into a single database is simply poor design. It's trivial to >>> create a separate database and why not use the tools that are available >>> instead of adding extra complexity?! >> I think the idea is to allow common authorisation between the two sites. > > I am a complete newbie here, so pardon me chipping in, but... would it > not be possible to do authorisation in one database and then have the > groups-specific databases being separate? > > Derek .. I don't think django allows multiple databases except via table name hacks and similar. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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: multiple projects shared database
Malcolm Tredinnick wrote: > On Wed, 2009-08-05 at 17:59 +0100, Robin Becker wrote: >> My boss wants to have two different django controlled websites with a common >> database. Is there a way to do this? >> >> We are already running multiple websites into a single django project and >> because they have a disambiguating term in the urls eg each url has >> /lang/brand/path we can map the URLs pretty well. >> >> With the multiple django projects & 1 database I am worried there are some >> hidden problems waiting to come out and play. > > The only potential problem is the content types. There are entries in > the content types table for each model and it needs to contain > information about all the models. So be careful when you're running > syncdb. I have already been bitten by the content types thing. I'm not sure I understand exactly what is using django_content_type, but one of our developers started using ContentType as part of an intermodel link structure and although it worked it is fragile since the content type ids are not guaranteed to be the same everywhere. > > What you're trying to do here is not dissimilar to just using different > settings files for the same database, as in this tip: > http://www.pointy-stick.com/blog/2009/03/26/django-tip-controlling-admin-or-other-access/ > > On the other hand, if the two websites are entirely independent, putting > them into a single database is simply poor design. It's trivial to > create a separate database and why not use the tools that are available > instead of adding extra complexity?! I think the idea is to allow common authorisation between the two sites. ... -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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 -~--~~~~--~~--~--~---
multiple projects shared database
My boss wants to have two different django controlled websites with a common database. Is there a way to do this? We are already running multiple websites into a single django project and because they have a disambiguating term in the urls eg each url has /lang/brand/path we can map the URLs pretty well. With the multiple django projects & 1 database I am worried there are some hidden problems waiting to come out and play. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-usable applications
We're trying to write some re-usable apps, but face some problems when it comes to configuring various bits of the application to run together. First off it seems reasonable to allow apps to locate their resources using settings.py. However, in one instance we're not able to do this. Specifically when widgets are created the Media subclass doesn't allow for any kind of initialization of the included javascript. So my colleague then has to force the app to load resources from a fixed location say /media/myapp/. In other places we're able to configure the javascript using a script tag eg var myapp_url_prefix='/notmedia/myapp'; Would it not be a good idea to allow widgets to enter things other than js and css in the head section. If 'script' were allowed as an attribute then widgets could also be configured relatively simply. There are also other bits of configuration which widgets could request eg onload/onunload etc etc. For most apps there's no real problem in having a fixed resource location, but I can see cases when proper configuration is desirable. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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 -~--~~~~--~~--~--~---
clear a newforms error indicator
We have some legacy code that wants to display a partially filled form. One of the fields is required to be non-empty (it's a captcha) so when re-issuing the form partially filled I've been doing this class EmailForm(forms.Form): . vericode = forms.CharField(max_length=5, required=True, label='CODE') ... nparams= params.copy() nparams['vericode'] = '' ef = EmailFormPangea(nparams) but I find then that the vericode field is marked as in error when I come to render. To fix this I tried ef = EmailFormPangea(nparams) ef.full_clean() del ef._errors['vericode'] but this looks fairly clunky. Is there a better way to clear errors or to indicate that something is not in error during rendering, but should be considered erroneous on submission? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: fastCGI: always one server per site ?
Valts Mazurs wrote: ... > > Any reason you went for processes rather than thread ? > > Robust, stable, no issues with GIL. > .. We run flup+apache+django with many hosts and only had problems when trying to run threaded. We are running different virtual machines into the same socket ie only one server. As for the long running process problem the solution seems to be 1) fork an external process that runs the long running part 2) in the parent return a view that queries the long running part (obviously you need to keep track of the PID etc etc). We have used javascript timeouts to call back to the server every few seconds. 3) when the long running part finishes any views that are polling the job see some kind of end marker and then stop polling. There are obvious dangers here. First off you don't want to be rerunning the jobs that are already running so some kind of queue might be useful. Secondly you really ought to kill running jobs for which no query has been received recently. Finally you ought to limit the resources consumed by the background jobs to keep the server response time reasonably fast. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
enforcing uniqueness
My boss, created a model that represents an override to parts of other model
instances; the business logic demands that the model instances should be
uniquely defined by two attributes a and b
ie
o1.a==o2.a and o1.b==o2.b <==> o1 is o2.
I know that we can implement validation rules in the admin to ensure that this
is so, but he prefers to merge an existing instance into the new version at
save
time and also delete the existing one. Is that in fact possible with django's
orm?
I'm thinking of code somewhat like this
def save(self):
P=list(Over.objects.exclude(id=self.id).
filter(a=self.a,b=self.b).order_by('id'))
if P:
for p in P:
self.merge(p)
p.delete()
super(Over, self).save()
would this work?
--
Robin Becker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: partially edit an object
koenb wrote: sted a snippet on > djangosnippets with my DisplayModelForm [1]. > Basically, it allows you to reuse your form definitions, but turn them > into a "display_only" mode. You can do all fields or just a few. > .. I've passed this to my colleague who will no doubt digest in due time; thanks. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
partially edit an object
I have a colleague who wishes to restrict the editability of fields dynamically. I can see how this arises by considering a Person object. The supervisor role might be allowed to edit more than the individual concerned. We looked in vain for an 'easy' way to do this using old forms, newforms, generic views etc etc, but eventually started writing our own views to do this. Sure I could probably start trying to grok the inner horrors of update_object and minulators etc etc, but that seems really overkill for such a simple requirement. I expected to be able to pass in a list of fields that were to be left alone or something as easy. Is there no easy way to do these simple extensions; if not what's the 'right' way to do this in the various contexts? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
IE6 problem
I have a problem with django administration and IE6. Basically no matter what I do I get a cookies problem when trying to log in to /admin. It seems that this website is permanently cookie blocked by IE6. I have tried going to the provacy policy etc etc internet settings, but nothing I do seems to make the site work (up to and including allowing unrestricted cookies in the internet settings). I'm using IE7/Firefox on the same site and that has no problems at all. I'm wondering if my test machine (which has both IE7/6 is the issue). Can anyone help? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
selenium versus django app
I have a bunch of really weird errors coming from selenium built with the IDE when running in proper selenium. The page in question is an admin form coming from the python django framework > info: Executing: |type | ctyhocn | gathi | > debug: Command found, going to execute type > error: Unexpected Exception: A script from "http://127.0.0.1:8000; was > denied UniversalFileRead privileges. The field in question appears to be completely unexceptional; it's just an input text box > following this message there appears to be a large amount of debug info related to some kind of string functions eg camelize, gsub etc etc. Can anybody tell me what's going on? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: shared state between requests and FastCGI
Amit Ramon wrote: > Hello, > > I'm developing a site that need to display ads. The ad to display on a page > is selected by a function based on the value of a global state - an > application state that need to be maintained across requests and different > users. In other words, the state is a "website singleton". > > This state is read and changed on every request. One trivial way to achive > this is to store the state in the database, but I'm afraid that changing the > value in the database with every request might create a performance > bottleneck (I'm using MySql, don't know if it matters). > > I thought about having a global (plain python) variable to store the state. > However, there are some points to think about, especially since I'm not sure > how FastCGI works: > 1. Is there single process that handles all the requests? (so it can keep > state) > 2. If so, are different requests handles by separate threads? If this is > true, then I probably need to make this state variable thread-safe. > 3. How long does the FastCGI process (or the relevant application process) > lives? I don't mind reseting the state from time to time, but not too often. > > The ad selection mechanism is somewhat probabilstic - ads should be displayed > more or less randomly (with some uniform or weighted distribution), so > another option I'm thinking of is using python's random() function to select > an ad. That way I won't have to maintian state explicitly, although a state > would be maintained by python for the random number generator. This also > raises some questions: again, to make this work well there need to be a > single server process, the random number generator (or its state) need to be > global. > > I hope this is not too long, and clear enough. I would appreciate any ideas. > > Thanks, > > Amit Ramon .. I think that unfortunately the top level django process spawns new processes (or threads) to handle concurrent requests. It all depends on the fcgi mechanism. I suspect the fcgi protocol assumes stateless behaviour like much else of the HTTP world so there's probably no obvious way to share state. Certainly the fork model essentially duplicates the parent and child before the child continues so there must be some way for the parent to communicate with the child, but I don't think there's any obvious way for the child to communicate back. In the separated case you really want the distribution function to satisfy a certain property eg additivity so having two independent generators and summing the results should look like the same distribution as one or three etc etc except perhaps for scale. Unfortunately I don't think that's true in general, it's certainly true for gaussians. If you really want to to this with a single generator then why not pass the add selection problem off to a service on your server ie put the whole problem into a singleton server with a fast response using say XMLRPC if all this has to do is compute a single draw from your function it should be fairly fast. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
fastcgi problems
I'm using apache2.0+mod_fastcgi with flup prefork django 0.95+. With large requests we see an error return from the server (not django), but using top I can see the python process (presumably for the large request) ticking away using up lots of memory/cpu. At some point the python process stalls (I think because it wants to write to the now defunct pipe or whatever). I see these messages in the apache error log FastCGI: comm with server "/...fcgi" aborted: idle timeout (30 sec), referer: FastCGI: incomplete headers (0 bytes) received from server "/...fcgi", referer: so I'm guessing that the apache end of the fastcgi pipe is timing out. Is there a way for the django/flup side to signal that the request is not dead. I find it a bit strange that the django side doesn't seem to care about whether the apache side is alive or dead. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: foreign key search
Karen Tracey wrote:
> On 12/3/07, Robin Becker <[EMAIL PROTECTED]> wrote:
>>
>> I have a simple model with a foreign key relation
>>
>> class A(models.Model):
>> id = models.CharField('ABCDEFG', .)
>
>
> Do you really have an explicit field named 'id'? Do you also include
> primary_key=True over in that '' part? Otherwise it seems you'd get a
> conflict between your explicitly id field and Django's auto-generated one.
id has primary_key=True
>
> class B(models.Model):
>> def __str__(self):
>> return self.name
>>
>> class Admin:
>> list_display = ('name',)
>> list_display_links = ('name',)
>> ordering = ('a', 'name')
>> search_fields = ('a__id','name')
>>
>> a = models.ForeignKey(A, num_in_admin=3)
>> name = models.CharField(maxlength=255, core=True )
>>
>
>
>
> the 'a__id' syntax is correct. I don't quite understand what "seems to
> locate some rows, but the listing page doesn't display." means. How can you
> tell what it found if the listing page doesn't display? What displays
> instead of the listing page -- an error, a blank page, a
> never-finishes-loading page...?
Well I see the search box, and when I enter the id of a known A and hit the go
button The page that returns has
"23 results (6380 total)" beside the go button and in the body of the page I see
23 as
however there's no other text in the page. I expected to see the rows that were
found.
After testing with different data I believe it's just one of my data rows
that's
vanishing.
>
> For a simple example from my own models that works for me, I have (from a
> legacy database so the names don't quite match what you'd expect for a
> Django app):
>
...
> Karen
...
--
Robin Becker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
foreign key search
I have a simple model with a foreign key relation
class A(models.Model):
id = models.CharField('ABCDEFG', .)
class B(models.Model):
def __str__(self):
return self.name
class Admin:
list_display = ('name',)
list_display_links = ('name',)
ordering = ('a', 'name')
search_fields = ('a__id','name')
a = models.ForeignKey(A, num_in_admin=3)
name = models.CharField(maxlength=255, core=True )
originally I had the search_fields=('a','name') but that failed to search at
all. My boss suggested that the documentation 'foreign_key__related_fieldname'
should be replaced by 'a__id' and that seems to locate some rows, but the
listing page doesn't display. I looked in vain for some simple examples, but
cannot get this simple behaviour to work. What's the 'right' way to search by a
foreign key?
--
Robin Becker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
middleware introspection
A colleague is writing a response middleware which hijacks the normal view under certain circumstances. Diagramatically V0 -->M(0)--> V1 is the normal case view V0 goes directly to V1 ie the middleware M does nothing. when the hijack is to take place V0 -->M(1)-->V2-->M(0)-->V1 Now my question can the middleware determine the template used by V0 so that it can be used automatically to generate V2? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: apache authorization with django
Graham Dumpleton wrote: .. >> >> I for one am not sure; are we saying that even if I'm using flup / fastcgi as >> the transport I'm not able to use that for authorization? > > That depends on whether flup supports the backend side of the FASTCGI > specifications authentication/authorisation mechanism. Ie., as setup > using the mod_fastcgi directives. > > # FastCgiAuthenticator > # FastCgiAuthenticatorAuthoritative > # FastCgiAuthorizer > # FastCgiAuthorizerAuthoritative > > I don't know what flup does, so you need to look at the flup source > code or any documentation for flup to work it out. > I'll need to take a look to see what it really supports. >> The real problem for me is deployment. We have multiple apps on the same >> machine. We have tried the multiple apache solution (ie a toplevel >> distributor >> with a secondary for the app) and found it wanting. Our preferred solution is >> fcgi as that allows us fully decoupled processes. Putting the authorization >> into >> mod_python seems to allow the possibility of cross talk even if we use >> separate >> interpreters. > > How do you think you can have 'cross talk'? There are issues with > running distinct users applications embedded within Apache using > mod_python, but if they are your own applications it shouldn't be an > issue as you wouldn't be deliberately trying to sabotage your own > stuff. .. although these are applications written by us they are often for different clients with possibly stringent security requirements. For the biggest clients we just give them a box of their own, for the snaller ones they get a shared app with a virtual host address. Having a common front end is a problem, as if something goes badly awry then possibly client a sees something client b has entered etc etc. The mod_python commonality is just another problem for security auditors. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: apache authorization with django
Graham Dumpleton wrote: . >> >>> In 2.0 there seems no way to provide another >>> authorizer without writing an apache module. >> Correct. > > Whoops. Not strictly true. You can write one with mod_python by > implementing a authzhandler(). You just need to know what you are > doing. ;-) > that's what the django approach is doing :) -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: apache authorization with django
Graham Dumpleton wrote: > On Sep 19, 3:05 am, Robin Becker <[EMAIL PROTECTED]> wrote: >> I find I can use django users and groups to authorize apache locations and >> directories using a modified version of modpython.py(I just hacked it to >> check >> for required groups). >> >> I have some difficulties with this simple scheme. >> >> First off it seems to be completely separate from the normal django >> behaviour. >> Is there a way to get existing django tokens to be used? So if I have already >> logged in or possess a django token can I use that token to provide access >> to an >> apache controlled area? >> >> Secondly the apache validation examples all seem to use mod_python as the >> transport between apache and django. We are tending to use fastcgi (via flup >> and >> runfcgi) as it gives us greater flexibility; we can use an entirely separate >> process for the python (perhaps even a different python). Is there a way to >> use >> a fastcgi based validation? >> >> Finally, my boss wants to use a single auth database. I'm not sure that's >> feasible, but it seems reasonable to have a central controlled database app >> which only does user/groups. I think this is less desirable because of the >> possibility of permission leakage. I can imagine exporting changes into some >> other project's db so this doesn't seem impossible. > > Can you perhaps gives some code examples of what your authn/authz code > looks like now so I can see how you are using groups. > > The reason I am curious is that I am currently working on implementing > a solution in mod_wsgi for better using Python to support Apache > authentication and authorization. Also, the other way around, > providing hooks so a Python application can use an Apache auth > provider for the auth database. This way one can have one auth > database across Python and non Python applications, plus static pages, > hosted by Apache. > . OK my code looks like the standard django/contrib/auth/modpython.py the patch is *** *** 39,44 --- 38,54 # check the password and any permission given if user.check_password(req.get_basic_auth_pw()): + G = [] #find required groups + S = filter(None,map(str.split,map(str.strip,req.requires( + map(G.extend,[filter(None,s[1:]) + for s in S if s[0].lower()=='group']) + for g in user.groups.all(): + if g.name in G: + G.remove(g.name) + + if G: #fail if required groups remain + return apache.HTTP_UNAUTHORIZED + if permission_name: if user.has_perm(permission_name): return apache.OK we're using this kind of phrase in our 2.0 apache configs AuthType basic AuthName "djauth test" Require valid-user Require group rptlab #AuthUserFile /home/rptlab/etc/passwd #AuthGroupFile /home/rptlab/etc/groups PythonInterpreter djauth PythonAuthenHandler djauth.modpython I'm guessing that AuthBasicProvider (in your examples) is new in Apache 2.2 and makes things easier for this. In 2.0 there seems no way to provide another authorizer without writing an apache module. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
apache authorization with django
I find I can use django users and groups to authorize apache locations and directories using a modified version of modpython.py(I just hacked it to check for required groups). I have some difficulties with this simple scheme. First off it seems to be completely separate from the normal django behaviour. Is there a way to get existing django tokens to be used? So if I have already logged in or possess a django token can I use that token to provide access to an apache controlled area? Secondly the apache validation examples all seem to use mod_python as the transport between apache and django. We are tending to use fastcgi (via flup and runfcgi) as it gives us greater flexibility; we can use an entirely separate process for the python (perhaps even a different python). Is there a way to use a fastcgi based validation? Finally, my boss wants to use a single auth database. I'm not sure that's feasible, but it seems reasonable to have a central controlled database app which only does user/groups. I think this is less desirable because of the possibility of permission leakage. I can imagine exporting changes into some other project's db so this doesn't seem impossible. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: non unicode
Malcolm Tredinnick wrote: > On Wed, 2007-08-29 at 14:58 +0100, Robin Becker wrote: >> Hi, we're having some troubles with latest django that are caused by the >> switch >> to unicode string output. In particular since we were already carefully >> handling >> the conversion and encoding of the database values we are now getting errors >> because the data is in unicode. Is it possible to disable the unicode >> conversion? > > No, it's not possible. The assumptions that strings will already be > Unicode is fairly tightly inter-twined throughout the code. To do > otherwise would, for example, really impact performance because we would > *never* be able to assume that things were in the right encoding and > have to call smart_unicode() everywhere -- the function call overhead > would be noticeable (I say this from having tested it). > > I'd like to hear details of what the actual problems are, so that we can > fix things rather than trying to hide them. I'm not going to be able to > work on anything like this for a little while (partly because of a > commitment to get some other code finished urgently), but we should fix > any difficulties. we're using the str operation in various places. The default unicode --> str encoding is ASCII and that now gets used whereas before utf8 str --> str was a no-op. We're not using binary data merely what was implicit in the idea of char fields. If Django had added unichar fields that would have allowed both kinds of field to be used and kept backward compatibility for those who need it. I'm advised that it's impossible to change the default encoding (it's done in site.py, but I was warned against messing with it by people on the Python development team). One way round my current problems would be to override the unicode type being used to allow a django unicode-->str encoding to be specified, but probably that's not feasible either as it seems everyone just uses unicode without regard to the intended final use. The suggestion that we unpatch a single back end is probably doable, but we'll have more and more problems as time goes on. > > I'm not going to be too surprised to hear that it's something like > trying to use binary-like data in text fields -- getting a proper binary > field and, most importantly, getting transparent transmission to and > from the database in play is a pretty big priority once I have time. > It's not completely trivial, but, again, a clear description of the > problems you are having might help guide the design. That will, in > effect, provide a way to have deliberately unencoded data in both a > designated binary field and also available for any custom field types > and should solve some problems I suspect exist. > > Regards, > Malcolm > > -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
non unicode
Hi, we're having some troubles with latest django that are caused by the switch to unicode string output. In particular since we were already carefully handling the conversion and encoding of the database values we are now getting errors because the data is in unicode. Is it possible to disable the unicode conversion? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Using **?
Greg wrote:
..
The ** thing can be used in two ways
1) to allow extra keyword arguments to be collected into a single dictionary
inside a function.
eg
def func0(a0,a1,a2,b0=30,b1=31,**kwds):
print a0,a1,a2,b0,b1,kwds
func0(0,1,2,c0=40,c1=42)
should print
0 1 2 30 31 {'c1': 42, 'c0': 40}
2) You can pass a dictionary into a function as though the keys were passed as
key=value.
eg
D=dict(a0=-0,a1=-1,a2=-2,b0=-30,b1=-31,c0=-40,c1=-41)
func0(**D)
0 -1 -2 -30 -31 {'c1': -41, 'c0': -40}
note that you can pass fixed arguments as though they were keywords. In the
function the **kwds argument picks up keywords that are not known in the
definition. If the dictionary didn't contain the fixed arguments (ie the ones
without defaults) we'd still have to pass those positionally
eg
D=dict(c0=50)
func0(10,11,12,**D)
10 11 12 30 31 {'c0': 50}
theer's an equivalent concept for positional arguments that uses a single *
--
Robin Becker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Calling different Django sites from the same external application
Hancock, David (DHANCOCK) wrote: > We have two Django "projects" with distinct settings files, and we need to > be able to make API calls to each of them from the same (separate) > long-running application. Using the API of one of them is easy--we've got > the DJANGO_SETTINGS_MODULE defined in the environment of the calling > process, and it works great. Now we're adding the second project's API > calls, and we're getting the settings of the first project. > > Has anyone got an idea for how to have two sets of settings active in the > same application at the same time? The one proposed solution (put the second > project inside the first one) seems a little too brute-force to me. > > Cheers! I did exactly this by having two settings files and changing the environment section in the apache container that we used to start off each application. PythonPath "['/usr/tmp/djcodeCODE']+sys.path" SetHandler python-program SetEnv DJANGO_SETTINGS_MODULE djcode.app.settings PythonHandler django.core.handlers.modpython #PythonDebug On PythonInterpreter app PythonPath "['/usr/tmp/djcodeCODE']+sys.path" SetHandler python-program SetEnv DJANGO_SETTINGS_MODULE djcode.app.test_settings PythonHandler django.core.handlers.modpython #PythonDebug On PythonInterpreter test_app -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django authorization of apache
Steven Armstrong wrote:
>
> You could then pass the groups, or whatever else you need, to the
> handler using PythonOption directives.
>
> e.g.
>
> AuthType basic
> AuthName "djauth test"
> Require valid-user
> SetEnv DJANGO_SETTINGS_MODULE djauth.settings
> PythonOption DjangoGroups XXX group2 group3
> PythonAuthenHandler path.to.my.auth.handler
..
well I hacked contrib/auth/handlers/modpython.py and now have group checking
with this code
# check the password and any permission given
if user.check_password(req.get_basic_auth_pw()):
G = [] #find required groups
S = filter(None,map(str.split,map(str.strip,req.requires(
map(G.extend,[filter(None,s[1:])
for s in S if s[0].lower()=='group'])
for g in user.groups.all():
if g.name in G:
G.remove(g.name)
if G: #fail if some required groups remain
return apache.HTTP_UNAUTHORIZED
if permission_name:
if user.has_perm(permission_name):
return apache.OK
else:
return apache.HTTP_UNAUTHORIZED
else:
return apache.OK
else:
return apache.HTTP_UNAUTHORIZED
--
Robin Becker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: django authorization of apache
Steven Armstrong wrote: > Robin Becker wrote on 06/28/07 16:13: >> I see from this documentation >> >> http://www.djangoproject.com/documentation/apache_auth/#configuring-apache >> >> that it is conceptually possible to configure apache authorization using >> django. >> >> However, we have recently decided to de-couple django from mod_python by >> using >> fastcgi. This is because we wish to allow our django apps to use which ever >> python might be appropriate and not restrict to the one for which we have >> compiled apache+mod_python. >> >> Is there any way to have mod_python stuck on Python-2.4 with the controlling >> django app use Python-2.5 and do configuration for apache. The only way I >> can >> think of is to create a stub project which runs the auth only. >> >> I know that theoretically we can advance the apache, but that implies >> re-installing wikis etc etc etc and when Python-2.6 comes out and the boss >> wants >> to use new feature X we'll go through the whole process again. >> >> Alternatively is there a way to do the reverse ie get django to use a >> database >> controlled by apache? > > You could directly access the database using something like > mod_auth_mysql or the like. But the way django stores passwords may be a > problem. yes it seems harder than setting up a dummy project. On the other hand our current scheme uses require group xxx and I cannot seem to get validation done that way. I have this in a .htaccess file AuthType basic AuthName "djauth test" Require valid-user Require group XXX SetEnv DJANGO_SETTINGS_MODULE djauth.settings PythonOption DJANGO_SETTINGS_MODULE djauth.settings PythonAuthenHandler django.contrib.auth.handlers.modpython I see the request for a user, but the validation seems to ignore the Require Group clause entirely. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
django authorization of apache
I see from this documentation http://www.djangoproject.com/documentation/apache_auth/#configuring-apache that it is conceptually possible to configure apache authorization using django. However, we have recently decided to de-couple django from mod_python by using fastcgi. This is because we wish to allow our django apps to use which ever python might be appropriate and not restrict to the one for which we have compiled apache+mod_python. Is there any way to have mod_python stuck on Python-2.4 with the controlling django app use Python-2.5 and do configuration for apache. The only way I can think of is to create a stub project which runs the auth only. I know that theoretically we can advance the apache, but that implies re-installing wikis etc etc etc and when Python-2.6 comes out and the boss wants to use new feature X we'll go through the whole process again. Alternatively is there a way to do the reverse ie get django to use a database controlled by apache? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: dynamically changing URLS
James Bennett wrote: On 1/8/07, Robin Becker <[EMAIL PROTECTED]> wrote: Is there any obvious way to get the dispatch mechanism to behave differently under specific circumstances? Not too long ago, there was some new functionality checked in to trunk which allows you to tell Django to use a different URLConf on a per-request basis, by having request middleware assign to 'request.urlconf' -- Django will then look at that for the root URLConf module to use, instead of the one specified in settings. The use case which inspired that was being able to switch URLConfs based on the value of the HTTP 'Host' header, but you might be able to adapt it to your needs. However, in your specific case I wonder if it wouldn't be better to just have a separate settings file with a different value for ROOT_URLCONF; when you need to upgrade, switch to that file temporarily, and then switch back when you're done. You're going to have to do server restarts either way if you're making code changes, so this seems the logical thing to do. thanks very useful stuff. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
dynamically changing URLS
Is there any obvious way to get the dispatch mechanism to behave differently under specific circumstances? We have a site where the clients can enter live data, but when we want to upgrade code/fix bugs etc we would like them to be locked out and a road up page to be shown instead. Assuming we have decision value the alternatives seem to be 1) Fix up those views which need to be hidden so they change representation when the value says hide. 2) Change the dispatcher so it knows to substitute different views when the hide signal is on. 3) some other mechanism not yet discovered Not wishing to fix all of our views (in particular the contrib/admin stuff) I tried 2 and had some success. I can get a resolver which either points to the original value or a generic road up page. Have others tried anything similar? -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: multiple projects one server
David Zhou wrote: On Jan 5, 2007, at 5:00 AM, Robin Becker wrote: so these define the server used by the http stuff below, do I understand it correctly that the fcgi processes are setup to listen on the above ports? Those are unix sockets, but correct. The fcgi processes are listen at those sockets. If so does nginx provide some mechanism to start them up or is it all handomatic? I have a script that starts them up, but yeah, AFAIK, there isn't anything in nginx or Django that starts them automatically. .. thanks David, real helpful -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: multiple projects one server
David Zhou wrote:
I'm running nginx + fcgi for Django, so the below is in nginx's config
format. But I'm assuming that lighttpd should be able to do something
similar.
Basically, in nginx, you can specify various upstream pools. For example:
upstream blah {
server unix:/tmp/blah.com_1.sock;
server unix:/tmp/blah.com_2.sock;
}
upstream foo {
server unix:/tmp/foo.com_1.sock;
server unix:/tmp/foo.com_2.sock;
}
so these define the server used by the http stuff below, do I understand it
correctly that the fcgi processes are setup to listen on the above ports?
If so does nginx provide some mechanism to start them up or is it all
handomatic?
then in the site definitions:
server {
listen 80;
server_name blah.com;
location / {
#insert FCGI params stuff here
...
##
fastcgi_pass blah;
}
}
server {
listen 80;
server_name foo.com;
location / {
#insert FCGI params stuff here
...
##
fastcgi_pass foo;
}
}
...
--
Robin Becker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
multiple projects one server
I'm unsure if this is a simple to answer issue or not. We've been using django simply for a while and are now starting to use it in a more production like setting. Since apache is our preferred server we tried using a single apache server with mod_python in virtual hosts. Each virtual host had its own interpreter, but for various reasons we decided it was too hard to prevent intra-interpreter interactions. The main problem being our own C accelerators; we currently don't have time to rewrite these to allow easy use with multiple interpreters/threads. Currently I am trying a two level approach with proxying; it seems to work. The apache in the second level handles only one of the upper level virtual hosts and since they are in a different process no interactions can happen. Clearly we have more apache processes than before and the restarts are harder etc etc. Is there a better way to handle this sort of thing using fastcgi or scgi? Can we get all requests from a particular host to be handled in only one group of processes. Our back end process doesn't respond well to being threaded and it can take a long time to complete so we seem to need a worker pool for each virtual host. Any ideas welcome. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Silly behaviour of exception output
Jeremy Dunck wrote: On 12/28/06, Robin Becker <[EMAIL PROTECTED]> wrote: ... no worries, in trac mode I added the patch then the patch and finally changed the summary to start with [patch]. -- And the uncaught exceptions? I'll do another one tomorrow. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Silly behaviour of exception output
Jeremy Dunck wrote: The django-developers list exists not just for people that have committer access, but for discussion of development -of- django, as opposed to django-users, which exists for people developing -with- django. I was making the suggestion because I'd like to see the improvements made, but sending a lone message to dju is a great way for it to be forgotten. Ticketing systems exist for a reason, I'm sure you'll agree. I'm willing to submit patches, but I really hope it's not trac which I dislike. Where should I submit these tickets etc etc. . If you can't bring yourself to make the tickets, please just make patches, and I'll do the dirty work of the ticket itself. no worries, in trac mode I added the patch then the patch and finally changed the summary to start with [patch]. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Silly behaviour of exception output
Jeremy Dunck wrote: On 12/28/06, Robin Becker <[EMAIL PROTECTED]> wrote: Our team has been using Django for about one year. I find it difficult to debug with Django despite the attempt at friendly traceback pages. It seems Django has failed to take advantage of the tracebacks that are available. This sounds like good input, but you'll have better luck if you 1) make a ticket and 2) send the message to django-developers. .. I don't much care for elite groups, but surely the developers list is for actual developers. I'm willing to submit patches, but I really hope it's not trac which I dislike. Where should I submit these tickets etc etc. -- Robin Becker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Silly behaviour of exception output
Our team has been using Django for about one year. I find it difficult to debug
with Django despite the attempt at friendly traceback pages. It seems Django has
failed to take advantage of the tracebacks that are available.
First off near line 97 of django/views/debug.py
if pre_context_lineno:
this test fails constantly because DJango seems to have the wrong path names for
most modules. It seems Django ends up with pathnames like
./core/handlers/base.py rather than django/core/handlers/base.py
The result of this failure is that the stack traces have missing frames and
often the actual error frame is missing. A simple patch to fix this silliness
Index: django/views/debug.py
===
--- django/views/debug.py (revision 4207)
+++ django/views/debug.py (working copy)
@@ -107,6 +107,20 @@
'post_context': post_context,
'pre_context_lineno': pre_context_lineno + 1,
})
+else:
+frames.append({
+'tb': tb,
+'filename': filename,
+'function': function,
+'lineno': lineno + 1,
+'vars': tb.tb_frame.f_locals.items(),
+'id': id(tb),
+'pre_context': '[unknown pre_context]',
+'context_line': '[unknown context_line]',
+'post_context': '[unknown post_context]',
+'pre_context_lineno': '[unknown pre_context_lineno]',
+})
+
tb = tb.tb_next
if not frames:
Secondly it seems that bugs in middleware are uncaught eg in
core.handlers.base.BaseHandler.get_response django/core/handlers/base.py line 58
# Apply request middleware
for middleware_method in self._request_middleware:
response = middleware_method(request)
if response:
return response
is not in the main try block so is not handled properly. Also the post
processing of responses is broken eg in django/core/handlers/modpython.py near
line 150
# Apply response middleware
for middleware_method in self._response_middleware:
response = middleware_method(request, response)
is outside of any try except block so cannot have a nice traceback.
A colleague is trying to use a middleware for logging successes and errors.
However, it seems that using process_exception only sees errors in the main
callback and not any other middleware methods. Again this seems to be caused by
the code in BaseHandler.get_response. Surely any error in middleware is as
damaging as an error in the main callback?
--
Robin Becker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
