Re: django auth for existing cgi
Copying things from request.META to the env parameter of Popen allows me to get the cgi off the ground. Now I have the problem that the cgi is generating a cookie and content type, which django returns to the browser as page content. Is there a way to pass it back transparently? Or, failing that, can someone point a newbie to an appropriate method to parse the header so it can be used to create a HttpResponse? On Mon, Dec 6, 2010 at 7:06 PM, Wayne Smith wrote: > > > On Mon, Dec 6, 2010 at 4:42 PM, bc wrote: >> >> Is there any simple way to use django authentication/authorization to >> control access to an existing (not django) cgi? >> >> I could use subprocess.Popen to invoke the cgi after checking >> authorization, but the environment needs to be set up to look like a >> cgi call (setting QUERY_STRING, etc.). Is there a better way? >> > > I don't know if you could do some special trick with an HttpRequest or some > kind of redirect from one view to hit the cgi script with the automatically > created (HttpRequest) data. I'm guessing the answer is no or more trouble > than it would be worth, but that's just a guess. > > I would say you really have two options. > > 1. Implement the script in Python, and bring it in under Django. > > 2. Craft your own Http Request header with Python's libraries and point it > to the cgi script. > >> >> -- >> 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. >> > > -- > 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. > -- 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.
serialize field name instead of "pk"
I have a model with a "name" field that is the primary key. When serializing, this field gets serialized as "pk" instead of "name". Is there an easy way to get django to serialize with the actual field name instead of changing it to pk? -- 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.
"drop table if exists" aborts
mysql generates an informational warning when running "drop table if exists " if the table doesn't exist. Django then throws an error and aborts. Is there a good way to avoid this? b.c. -- 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.
double trailing slash in url
I have a url spec like so:
(r'^foo/$', 'blah')
I just noted from our server logs that if someone mistakenly types two
slashes ('foo//'), the page
gets served, but all of the relative links are broken. It's really
confusing. I believe it should be redirecting or 404ing instead.
I note that foo/bar and foo/bar/ give 404.
I thought that ending in a $ would prevent this from matching.
--
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: double trailing slash in url
I don't think so. It's not issuing a redirect. It's just serving the view, even though the url spec doesn't match. On Thu, Dec 1, 2011 at 2:42 PM, creecode wrote: > Hello Brain, > > Could it be you are seeing the results of the APPEND_SLASH setting < > https://docs.djangoproject.com/en/1.3/ref/settings/#append-slash >. > > Toodle-loo... > creecode > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/vjH3Q5JCwXgJ. > 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. -- 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.
ModelChoiceField with multiple databases
Is there an easy way to use a ModelChoiceField with multiple databases? The only thing I've seen that looks promising is overriding the form __init__ and setting the queryset for the field. Seems kinda clunky. -- 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.
logging sql queries during unit test
Is overwriting settings.DEBUG the recommended way to get connections[db].queries to work during a unit test? -- 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.
syncdb not creating join table
I have two models. The second one has a ManyToMany to the first. Both are managed. If I drop both tables and run syncdb, only the two model tables are created. There's no join table. syncdb doesn't report any errors. "validate" shows 0 errors. Any ideas what the problem could be, or how to debug it? I'm using multiple databases, and setting the table names for the two models via the Meta class. -- 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: syncdb not creating join table
I strongly suspect the problem I'm having has to do with database routers. It looks like under the hood django creates a model to represent the m2m relationship, and the router is blocking the syncdb for the generated model. I was using a class attribute on my models to control the routing, but I don't have control of that on the generated model. On Wed, Jan 4, 2012 at 10:57 AM, Brian Craft wrote: > I have two models. The second one has a ManyToMany to the first. Both > are managed. If I drop both tables and run syncdb, only the two model > tables are created. There's no join table. syncdb doesn't report any > errors. > > "validate" shows 0 errors. Any ideas what the problem could be, or how > to debug it? I'm using multiple databases, and setting the table names > for the two models via the Meta class. -- 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: syncdb not creating join table
Looks like a m2m class can be identified by the ._meta.auto_created attribute, which also holds the class with the m2m field. So the router can check for attributes on that class. On Wed, Jan 4, 2012 at 11:49 AM, Brian Craft wrote: > I strongly suspect the problem I'm having has to do with database > routers. It looks like under the hood django creates a model to > represent the m2m relationship, and the router is blocking the syncdb > for the generated model. > > I was using a class attribute on my models to control the routing, but > I don't have control of that on the generated model. > > On Wed, Jan 4, 2012 at 10:57 AM, Brian Craft wrote: >> I have two models. The second one has a ManyToMany to the first. Both >> are managed. If I drop both tables and run syncdb, only the two model >> tables are created. There's no join table. syncdb doesn't report any >> errors. >> >> "validate" shows 0 errors. Any ideas what the problem could be, or how >> to debug it? I'm using multiple databases, and setting the table names >> for the two models via the Meta class. -- 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.
integrity error with transaction middleware, django 1.3
I'm getting duplicate entry integrity errors when saving an object, with transaction middleware enabled in django 1.3. I thought the point of the middleware was to rollback transaction errors and retry the view. Why would I be getting this error? The db is mysql. The save code looks like this: try: gs = request.user.usergeneset_set.get(name=name) gs.genelist = members except ObjectDoesNotExist: gs = UserGeneset(user=request.user, name=name, genelist=members) gs.save() -- 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. For more options, visit https://groups.google.com/groups/opt_out.
object with version
I need to create objects with version tracking, a bit like wiki content. Anyone done this in django? I could create a model with a content field and a version field. But I'm not sure how to query (for example) all the latest versions of a set of objects. I'm sure there's a raw sql method via joins, but is that the best way in django? -- 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.
form CharField null vs blank
A form with a CharField seems to end up with a zero-length string in the cleaned_data if the field is not in the form data. Is there any good way to avoid this? -- 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.
unit testing and file location
I would like unit tests that do file manipulations to run with a different storage "location", so they're not manipulating real app files. Is there a good way to do this? Is there a way to override model field initializers, so I can instance a model, passing in the 'storage' parameter for an ImageField in the 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-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.
imagefield upload_to
I have a model with an imagefield, and some fields that are computed from the image. I'm trying to override the "save" method to fill in the other fields. When I test this in the admin, there are two problems: first, the path (mymodel.image.path) doesn't honor the upload_to setting on the field. It concats MEDIA_ROOT and the file name, w/o the upload_to. (This is django 1.2.3). Second, I don't see the file in the filesystem when .save() is called. Perhaps save() is the wrong place to do this? If I don't try to generated the computed fields, the file is created in the correct (upload_to) directory, and if I read the object from the db, mymodel.image.path is also correct. Looks like upload_to is only accessed during FieldFile.save(), where the self.name is updated, so the path is always wrong before that. And apparently the file isn't committed to storage until the field is saved. Is there some other way to access the file before it is saved? -- 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: imagefield upload_to
solved this by moving it to the model clean() method, and using imagefield.file.open() and imagefield.file.read() to get the data for computing the other fields. On Wed, May 11, 2011 at 1:28 PM, Brian Craft wrote: > I have a model with an imagefield, and some fields that are computed > from the image. I'm trying to override the "save" method to fill in > the other fields. > > When I test this in the admin, there are two problems: first, the path > (mymodel.image.path) doesn't honor the upload_to setting on the field. > It concats MEDIA_ROOT and the file name, w/o the upload_to. (This is > django 1.2.3). Second, I don't see the file in the filesystem when > .save() is called. Perhaps save() is the wrong place to do this? > > If I don't try to generated the computed fields, the file is created > in the correct (upload_to) directory, and if I read the object from > the db, mymodel.image.path is also correct. > > Looks like upload_to is only accessed during FieldFile.save(), where > the self.name is updated, so the path is always wrong before that. > > And apparently the file isn't committed to storage until the field is > saved. Is there some other way to access the file before it is saved? > -- 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.
default group for new users
Is there a good way to add new users to a default group when they are created (e.g. via django-registration)? I just tried binding the post_save signal for User, and adding the group in the signal handler (if "created" is true). However, I haven't found a good place (file) to put the connect() call, so the signal will be caught: i.e. some file that will consistently be loaded before a User is created. I'm currently thinking I will override the django-registration activate url, and add the code there, before calling registration.views.activate. Obviously this isn't the most general solution. -- 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: default group for new users
After much googling, I created a new app called "core" and put the connect() in the __init__.py. That seems to be working. The problem with the "put it in models.py" solution is that it isn't really related to any of my existing apps. Previously I tried putting it in the project __init__.py, but that works inconsistently, apparently because django isn't fully initialized when the project __init__.py is loaded. On Tue, May 17, 2011 at 11:07 AM, Brian Craft wrote: > Is there a good way to add new users to a default group when they are > created (e.g. via django-registration)? I just tried binding the > post_save signal for User, and adding the group in the signal handler > (if "created" is true). However, I haven't found a good place (file) > to put the connect() call, so the signal will be caught: i.e. some > file that will consistently be loaded before a User is created. > > I'm currently thinking I will override the django-registration > activate url, and add the code there, before calling > registration.views.activate. Obviously this isn't the most general > solution. > -- 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.
overriding widget for "group" in User model
Is there an easy way to get checkboxes for groups in the User admin, rather than a multiselect? -- 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.
wsgi.file_wrapper failing silently
I'm testing the patch for ticket 2131 (http://code.djangoproject.com/ticket/2131) on 1.2.3. I'm getting back a 500 (internal server error) sometime after returning the HttpResponseSendFile(), with nothing in the apache error log. Any suggestions on how to debug this? -- 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.
calling django auth from apache RewriteMap
I'm interested in using RewriteMap (from mod_rewrite) to check for a django user session. That is, RewriteMap would invoke some script which would return session info, which could be used by mod_rewrite to allow or deny access. Basically, this would require writing a standalone python script that returns session information about a request. E.g. apache would write the session credentials (sessionid cookie?) to the script stdin, and the script would return information about the session (e.g. whether logged in, group membership, or etc.). Can anyone point me in the right direction? I need to know what information django requires to validate a request (look up a session), and what methods I could use to invoke it standalone. -- 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.
Group methods
Are there docs somewhere for the Group methods? E.g., I discovered through extensive googling that I can call user.groups.all(), but I can't find docs of an "all()" method, or any other method for Groups. If there aren't docs, how does one discover the methods? -- 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.
standalone session checking
I'm trying to implement a stand-alone python script to check a session cookie for group authorization. I cribbed from the auth and session middleware, so I could take the sessionid from the cookie, look up the session, look up the user, and get the list of groups. This all basically works, except for the very first time a session is seen. The first lookup always fails. I know the session is good (a call to a django view via @login_required, for example, works fine). I'm expecting this is some problem with a cache, or evaluation order, such that my script doesn't have the latest info from the db until I've queried it once. Anyone have a clue? Here's what the auth checking routine looks like: def authorized(session_id, group): ss = engine.SessionStore(session_id) session=ss.load() try: user_id = session[SESSION_KEY] backend_path = session[BACKEND_SESSION_KEY] backend = load_backend(backend_path) user = backend.get_user(user_id) or AnonymousUser() except KeyError: user = AnonymousUser() return user.groups.filter(name=group).count() It's called from a "while 1" loop in a script that never exits. The first time a session cookie goes through this routine, it always fails. Second, and subsequent times work. -- 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.
caching of Models (not the cache middleware)
Digging into the problem I'm having with a standalone django script, the problem seems to be that django doesn't see updates to the database unless it writes to the database. In the following lines, ss = engine.SessionStore(session_id) session=ss.load() If session_id "abcd" has been added to the session table after the script started, the load will not find it. Instead, it will create a new session, say "wxyz" and write it to the table. After writing it to the table, a subsequent load on "abcd" will succeed: it's now in sync with the database, at least until another process writes to it. Anyone know where this caching is happening? I have no caching middleware enabled. Does django cache results of Model queries? Or would the db layer be caching it? And how can I get django to sync before looking up a session? -- 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: caching of Models (not the cache middleware)
Thank you! 'set transaction isolation level read committed' had no effect, but 'set autocommit=1' appears to fix it. I wondered if there was some more general way of doing this (I mean, besides passing in raw sql). Perhaps the set_autocommit() method in db.backends.creation? On Fri, Jan 28, 2011 at 6:51 PM, Karen Tracey wrote: > On Fri, Jan 28, 2011 at 9:45 PM, Brian Craft > wrote: >> >> Digging into the problem I'm having with a standalone django script, >> the problem seems to be that django doesn't see updates to the >> database unless it writes to the database. > > Sounds a lot like: > http://groups.google.com/group/django-users/browse_thread/thread/e25cec400598c06d/ > > Karen > -- > http://tracey.org/kmt/ > > -- > 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. > -- 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.
newbie question about paths
Suppose the project is /var/www/django/project. Following the django with wsgi docs, you would add /var/www/django to the path, and DJANGO_SETTINGS_MODULE would be project.settings. However, in that case, the path scheme described in the tutorial doesn't work, e.g. setting up admin.py for Polls as described will throw an error because it can't find a module Polls. Instead you have to "from project.Polls.models import Polls", which seems to break the modularity of the Polls app (since it has the project name embedded in it, now). So, should the wsgi config instead add /var/www/django/project to the path, and set DJANGO_SETTINGS_MODULE to "settings"? -- 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: caching of Models (not the cache middleware)
The behavior seems to have reverted after a couple days. I suspect that the connection to mysql is being renegotiated, during which it loses the autocommit setting. This seems like it should be a setting in django, so if it renegotiates it will set autocommit again. Another solution might be to explicitly commit after every select. On Fri, Jan 28, 2011 at 6:51 PM, Karen Tracey wrote: > On Fri, Jan 28, 2011 at 9:45 PM, Brian Craft > wrote: >> >> Digging into the problem I'm having with a standalone django script, >> the problem seems to be that django doesn't see updates to the >> database unless it writes to the database. > > Sounds a lot like: > http://groups.google.com/group/django-users/browse_thread/thread/e25cec400598c06d/ > > Karen > -- > http://tracey.org/kmt/ > > -- > 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. > -- 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.
csrf cookie security
I notice that the csrf token is not secure, i.e. the Set-Cookie is constructed w/o the "secure" option, so the browser will send it in-the-clear. It's trivial, then, for a 3rd party to discover the csrf token. Am I missing something? -- 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: csrf cookie security
I thought, rather, that the csrf token was a cookie that was put in a hidden form field. With firebug or webkit dev tools you can see the django csrf token in the cookies. I would also refer you to middleware/csrf.py, where you can see it doing the set_cookie. I thought the security of the csrf token relied on the fact that the 3rd party wouldn't know what value to put in the hidden form field. The csrf middleware is, I believe, validating the value in the form field, against the value in cookie. But when it creates the form, it uses the value in the cookie. If the token is stored in an insecure cookie, it can be sniffed. Then I don't understand what prevents the attacker from constructing a valid form. On Wed, Feb 9, 2011 at 11:36 AM, Ian Clelland wrote: > On Wed, Feb 9, 2011 at 11:23 AM, Brian Craft wrote: >> I notice that the csrf token is not secure, i.e. the Set-Cookie is >> constructed w/o the "secure" option, so the browser will send it >> in-the-clear. It's trivial, then, for a 3rd party to discover the csrf >> token. >> >> Am I missing something? > > The CSRF token isn't a cookie (or at least, it shouldn't be) -- it's a > form field. The security principle behind the CSRF token isn't so much > that it's not discoverable, as much as that an attacker can't > construct a link that gets your browser to submit it to the server. > > If you site is under SSL (you're talking about secure-only cookies, so > I presume that this is the case,) then the CSRF token should only > appear in the HTML forms that the server sends to your browser, and > the POST requests that your browser makes back, both of which should > be protected. > > If the CSRF token was set in a cookie, then it would be sent with > every single request that the browser made, and it really would be > trivial for an attacker to get you to make a valid request of the web > server, whether he could discover the contents of that cookie or not. > (SSL wouldn't even help; he could construct an https:// link just as > easily.) That's not how it's supposed to be set up, though. > > -- > Regards, > Ian Clelland > > > -- > 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. > > -- 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: csrf cookie security
I'll have to look at this in more detail, but two notes, off-the-top. First, port 80 is kept open because the browser will try port 80 if the user types in the url without the protocol. On port 80 all we do is issue a redirect to https, but the client will have spilled the cookies by then. Second, the most like scenario for this to happen is with a wireless MITM. E.g. an attacker sits in, or near a coffee shop, or office, with a laptop setup as an AP, trolling for connections from unsuspecting users. If anyone connects, the laptop can be used as a MITM. So, for example, when the user types the url and hits port 80, the MITM can create an https connection to the target site, and return it via http. I'm not certain there's a csrf attack here, but I suspect there is. On Wed, Feb 9, 2011 at 11:28 PM, Ian Clelland wrote: > On Wed, Feb 9, 2011 at 11:51 AM, Brian Craft wrote: >> I thought, rather, that the csrf token was a cookie that was put in a >> hidden form field. > > You're absolutely right; I wasn't thinking about that side of the token. > >> With firebug or webkit dev tools you can see the django csrf token in >> the cookies. I would also refer you to middleware/csrf.py, where you >> can see it doing the set_cookie. >> >> I thought the security of the csrf token relied on the fact that the >> 3rd party wouldn't know what value to put in the hidden form field. >> The csrf middleware is, I believe, validating the value in the form >> field, against the value in cookie. But when it creates the form, it >> uses the value in the cookie. >> >> If the token is stored in an insecure cookie, it can be sniffed. Then >> I don't understand what prevents the attacker from constructing a >> valid form. > > If you want a secure cookie, that means that your entire site (or at > least the form-handling bits) must already be protected by SSL (since > a secure cookie will only be returned over an SSL connection). > > The threat model you are proposing, then, sounds like this: There is a > website, running Django, using Django's CSRF protection, in which all > of the form-handling views are only accessible over HTTPS, but there > are other resources in the same domain (or its subdomains) which are > accessible over HTTP. > > Further, there is an attacker, who can sniff the unencrypted HTTP > traffic, and can construct an HTML page at a different site (this is > Cross-Site Request Forgery, after all) > > A lot of the potential damage seems to be mitigated by another check > in django/middleware/csrf.py, for HTTPS requests only, that inpects > the referer header of the incoming request, to ensure that the browser > was not submitting the form from a different site. To get around that, > the attacker would have to be able to construct a form on the > SSL-protected site (a serious html-injection vulnerability would have > to be present), or cause the request to be submitted over plain HTTP > -- but the site is already HTTPS-only, so there shouldn't be any > form-handling code listening on that port. > > Does this threat model correspond to what you're thinking? If so, I > don't see away around the CSRF protection (at least, not one that > involves the victim's browser) > > > -- > Regards, > Ian Clelland > > > -- > 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. > > -- 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.
current recommendations for using email as username
I've found any number of threads on using email as username in django, but none that are both current and conclusive. "Just do ", followed by "But that breaks [the forms, the templates, the auth site, the registration, the db schema]" etc., where is something like "use email in the User username column", "use a randomly generated username", "use a hash for username", "write your own auth backend", "use django-emailauth", etc. What is the current state of this? -- 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: current recommendations for using email as username
On Fri, Mar 4, 2011 at 1:34 PM, Shawn Milochik wrote: > What's wrong with writing your own auth backend? It's two piddly functions: > > http://dpaste.com/hold/473373/ > I think this has already been answered, in the comments here: http://djangosnippets.org/snippets/74/ and in the "motivation" section, here: https://github.com/redvasily/django-emailauth -- 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: current recommendations for using email as username
On Tue, Mar 8, 2011 at 12:53 PM, william ratcliff wrote: > If you look through the code in the django admin, then the limit is set in > the database schema. I've read elsewhere that it's also in all the auth form validations, so you have to subclass all of them. I haven't actually investigated this myself. -- 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.
database connection from long lasting script
I have a script that sits in a loop, doing occasional queries, something like while 1: wait.for.some.event() object=get.some.django.db.object() do.something.with(object) transaction.commit_unless_managed() The last line is required so the script will see updates to the database from other processes. If there's no event for a long time, the database wait timeout is exceeded, and the script aborts with a "mysql sever has gone away" message. This is expected. What is surprising to me is that the error consistently happens during commit_unless_managed(). It's been waiting for an event for 8+ hours, finally gets one, appears to do a db query, and then aborts during commit because the connection is gone. What's going on here? Is this a caching issue? Django satisfies the query w/o touching the db, then aborts when updating with the db? If this is the case, I suspect the commit should be just after the wait. -- 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.
mysql OperationalError
When a long-running script loses the db connection, I get this exception: _mysql_exceptions.OperationalError Is there any way to trap this in a database-agnostic way? Or must I hard-code it to mysql? -- 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.
how to get csrf cookie in ajax app
In an ajax-based site, where the page is static, and makes ajax calls after loading, how would one get a csrf cookie? There aren't any templates associated with the views (they just return json strings). Setting of the cookie seems to be a side effect of serving forms in django, but the client doesn't need to fetch a form from the server for ajax calls. render_to_response finds a reference to the csrf in the template, calls some internal function to retrieve the csrf, which sets some flag causing the csrf middleware to add the set-cookie to the response. Or something? So, for an ajax app, I could create a view with an empty form, including just the csrf? Or create a view that calls get_token()? -- 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: how to get csrf cookie in ajax app
Yeah, I'm using that technique. It works fine once you have the cookie. My question was about how to get the cookie, which is not described well in the documentation. Manually calling get_token() in the view for the first ajax GET seems to be working. After that I can POST to other views. On Sat, Mar 19, 2011 at 12:11 PM, Matt Robenolt wrote: > This is actually something new coming in Django 1.3, and by default is > requiring all AJAX request to define an X-CSRFToken header. Fortunately, > they've written about how to do it here and provided a jQuery > implementation: http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax > > -- > 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. > -- 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: how to get csrf cookie in ajax app
It's in a cookie once you coerce django into sending the cookie to the browser. This is less automatic for ajax apps, because django isn't serving the forms (which is when it usually sends the csrf cookie). On Mon, Mar 21, 2011 at 9:49 AM, Matt Robenolt wrote: > To get the token? It's stored in a cookie. You can read that in Javascript > with document.cookie, then parse the cookie string to retrieve the relevant > part. > > -- > 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. > -- 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: how to get csrf cookie in ajax app
No, it's not. It's a static file. On Mon, Mar 21, 2011 at 10:23 AM, Matt Robenolt wrote: > Is your main view being rendered by Django or something else? If so, you'll > have access to the cookie. > > On Mar 21, 2011, at 1:09 PM, Brian Craft wrote: > >> It's in a cookie once you coerce django into sending the cookie to the >> browser. This is less automatic for ajax apps, because django isn't >> serving the forms (which is when it usually sends the csrf cookie). >> >> >> On Mon, Mar 21, 2011 at 9:49 AM, Matt Robenolt >> wrote: >>> To get the token? It's stored in a cookie. You can read that in Javascript >>> with document.cookie, then parse the cookie string to retrieve the relevant >>> part. >>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > > -- > 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. > > -- 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.
