Re: Loading initial data with a post_syncdb hook?
On May 9, 12:24 pm, Karen Tracey wrote:
> On Mon, May 9, 2011 at 12:56 AM, Adam Seering wrote:
> > On May 8, 10:53 pm, Karen Tracey wrote:>
> > > The change you have noticed is documented in the 1.3
> > > backwards-incompatibility list:
> >http://docs.djangoproject.com/en/1.3/releases/1.3/#use-of-custom-sql-...
>
> > Actually, that's a different issue: I'm not using the custom-SQL
> > loader, I'm using Python code with the post_syncdb hook. This one
> > isn't in the backwards-compatibility page as far as I can tell.
>
> > (Was that comment intended to cover this case as well? Maybe a typo
> > somewhere?)
>
> Hmm, you are right, this change is not supposed to affect data added via
> post_syncdb handlers. Specifically the change here
> is:https://code.djangoproject.com/changeset/15239. On an initial read it looks
> like it might cause post_syncdb-added data to get thrown away, since the
> post_syncdb signal is sent during the call_command('syncdb'). However, the
> call_command('flush', ...) that was added after the call_command('syncdb',
> ...) will also cause that signal to get sent.
Ah, I see what's going on. Apologies; it sounds like this was a mess-
up / misunderstanding on my part: Our syncdb hooks aren't safely
reentrant or re-runnable; they're not idempotent, and they depend for
correctness on having a clear django.core.cache to run queries against
and to push stuff into (or at least a cache that we haven't already
stuffed rows into that have since been deleted from the database but
not the cache; we have a fancy system that listens to post_delete to
keep the cache in sync with the database, but it looks like "flush"
doesn't fire post_delete?). Most were written prior to Django's handy
"dispatch_uid" deduplication mechanism, so they have a simple one-off
global latch that only allows them to run once. So they ran once for
the syncdb, then the "flush" cleared out all the database data and
they didn't run again the second time around. My mistake was to look
at the queries being sent to the database, see the data being loaded
and the following TRUNCATE, and assume that things were supposed to
stop there.
(Out of curiosity, any idea why this was done this way? It feels a
bit odd to me to generate data, throw it out, and generate it
again... Could the SQL-loader just be turned off during "./manage.py
test" runs?)
This mostly leads to a nice clean obvious solution: Make our loading
functions be safely reentrant and go start using dispatch_uid. One
new problem, though: We'll have to do something to flush the cache
whenever "flush" is called, so that stale data doesn't get left
behind. Should be quite doable, if a little clunky.
> > Right now, we're working on adding tests, and on encouraging
> > developers to write tests for new parts of the code, new apps/code
> > that are being developed, etc. Right now, as I understand it with
> > Django's current behavior and our post_syncdb hook setup, we want to
> > re-load the data in three cases: (1) The current test is the first
> > test, (2) all prior tests are TestCase (as opposed to
> > TransactionTestCase) instances, or (3) we are a TransactionTestCase
> > instance.
>
> (...) In fact
> Django will run all TestCase tests before any TransactionTestCase tests (as
> noted in the
> dochttp://docs.djangoproject.com/en/1.3/topics/testing/#testcase), precisely
> because the mechanism used to reset the database for these different kinds
> of tests can't ensure that a TestCase run after a TransactionTestCase will
> see a "clean" database on start.
Ah, ok: Because that text listed "(e.g. doctests)" as the
counterexample, and since it seemed to be comparing both
django.test.TestCase and django.test.TransactionTestCase, I took the
first sentence of that paragraph to mean "A unittest.TestCase, on the other hand, ...". If all the TransactionTestCases are at
the end as well, then that does in fact get rid of the weird edge
cases that I cited, modulo doctests as you noted (which we do use
occasionally but not very often).
Thanks,
Adam
--
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: Loading initial data with a post_syncdb hook?
On May 8, 10:53 pm, Karen Tracey wrote: > On Sun, May 8, 2011 at 10:13 PM, Adam Seering wrote: > > (Incidentally, sorry if this is a duplicate; my original reply, > > identical text, doesn't show up on groups.google.com...) > > I don't know why, but google groups decided your original message might be > spam so held it. When it makes that decision for anyone other than a new > user, it doesn't bother to send a note to moderators until a few days later. > It's a great feechur of google groups. I have removed the copy that was held > for moderation so as to avoid the duplication. Ah, thanks! > > The change you have noticed is documented in the 1.3 > backwards-incompatibility > list:http://docs.djangoproject.com/en/1.3/releases/1.3/#use-of-custom-sql-... Actually, that's a different issue: I'm not using the custom-SQL loader, I'm using Python code with the post_syncdb hook. This one isn't in the backwards-compatibility page as far as I can tell. (Was that comment intended to cover this case as well? Maybe a typo somewhere?) > > Of the alternatives you list, using setUp seems like the correct approach. > I'm a little confused by your worry both that you're inevitably going to > forget to put a call somewhere where it is needed and simultaneous statement > that it's going to be causing duplicate work in a lot of places where it > isn't really needed, though. It seems like you ought to be able to figure > out where it is needed and put it there (possibly helped by tests that fail > due to it not being there). Hm; I'm not entirely sure why you're confused, it's certainly something that'll be a bunch of work for us... Perhaps you're assuming that the set of tests are reasonably static, so that it's possible to go through and do this once? Let me take a shot at clarifying; let me know if this helps: Right now, we're working on adding tests, and on encouraging developers to write tests for new parts of the code, new apps/code that are being developed, etc. Right now, as I understand it with Django's current behavior and our post_syncdb hook setup, we want to re-load the data in three cases: (1) The current test is the first test, (2) all prior tests are TestCase (as opposed to TransactionTestCase) instances, or (3) we are a TransactionTestCase instance. So I can't look at any given test to tell you whether the data has to be loaded or not; I need to know what test(s) have run before it. And this will change if we add new tests, and the result may cause breakage not in the current code but in other pre-existing tests, making it a pain to track down for anyone who doesn't know this particular quirk. We could just load it every time, but that would slow down our test runs more than I'd like. Also, it would involve adding the same one line to every setUp() method, and remembering to add it to new tests, etc. Which I guess isn't the most onerous thing, but, I mean, it's repeating the same line of code over and over again; is that not work duplication? What I personally wish that Django did in this case would be to trust the data that syncdb puts into the database; do the necessary bookkeeping to restore it to its initial state at the end of each test as needed. If I thought it would be accepted, I'd submit a patch. But if it were that simple, I assume someone would have done it that way at the start; I don't know enough about this project to understand the reasoning behind the TRUNCATE here in any case... Hopefully that'll do a better job framing of what I'd like to accomplish with our code, though. Thanks, Adam -- 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: Loading initial data with a post_syncdb hook?
On May 8, 7:16 pm, Jacob Kaplan-Moss wrote: > On Sun, May 8, 2011 at 4:25 PM, Adam Seering wrote: > > I have some Python code that generatesinitialdatafor some of my tables; I > > currently call that code from a post_syncdb hook. In Django 1.3, it looks > > like > > Django now calls TRUNCATE (or an equivalent non-PostgreSQL-ism) on all > > tables > > after running syncdb and all of itspost- hooks. > > That... doesn't sound right. Here's all the SQL syncdb executes (for a > simple app with one table); notice the distinct lack of any TRUNCATE > statement. > > Are you perhaps talking about doing this during testing? If so, you're > looking for unittest's setUp > method:http://docs.python.org/library/unittest.html#unittest.TestCase.setUp. Oh, sorry, yeah; let me clarify: Our code has initial database data that it needs in general to operate as intended, during tests or otherwise. Mostly (though not exclusively) to do with a plugins system; scanning a subdirectory for matching .py files and detecting the features that they export is a little expensive, particularly in the critical path of page-rendering; much faster to do it once in advance. The TRUNCATE is during tests, though. If we were to use TestCase.setUp, I would need to modify each of our test classes to call each of our post_syncdb data-set-up hooks. This seems inelegant somehow; someone's going to forget one, and it's redundant work (and so slower tests) because most of our tests aren't TransactionTestCases and so don't need to re-create all of the data. I could monkeypatch TestCase, and possibly even patch some hooks into django.core.management.flush.Command.handle_noargs or django.db.backends.*.DatabaseOperations.sql_flush to know when data has been flushed so that I don't have to restore it unnecessarily. That feels complicated and fragile, though; I'm not a fan if I can avoid it... If the appropriate signals existed in the test framework, I could hook them and do something mildly creative and achieve the same effect as the above using public API's and no monkeypatching. Unfortunately, it looks like they don't exist just yet; I just gave Trac #14319 a gentle poke along those lines. All of these seem way too complicated, though. Am I missing the forest for the trees?; is there a simpler solution here? Thanks, Adam (Incidentally, sorry if this is a duplicate; my original reply, identical text, doesn't show up on groups.google.com...) -- 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.
Loading initial data with a post_syncdb hook?
Hi, I have some Python code that generates initial data for some of my tables; I currently call that code from a post_syncdb hook. In Django 1.3, it looks like Django now calls TRUNCATE (or an equivalent non-PostgreSQL-ism) on all tables after running syncdb and all of its post- hooks. I know I could use fixtures, but it's much more readable for us to use Python code for this initial data. (The data being generated is somewhat complex and denormalized for various reasons that probably won't be changed just for the sake of this issue..., but there are nice clean simple Python functions to create each entry.) Is there a good way to do so in the brave new Django 1.3 world? Thanks, Adam -- 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: Prevent brute-force password attacks?
Hi, Jorge: Thanks for the link; that's close to what we want. It looks like it's not so good at blocking broadcasts: f4nt: Actually, convincing users to choose smarter usernames/passwords would not help us much: We run online registrations for large (in-person) events. Our contact time with each user is very short, our ability to field support requests is quite small, and a subset of our users are very much not technically savvy (so forcing them to create good passwords would create a significant support burden). Also, the cost of an individual account compromise is relatively low; the only real cost would be exposure of that user's moderately-sensitive personal information (name/address/phone# at worst; no CC#/SSN/etc), and we're comfortable saying "hey, you chose a really bad password; we tried, but there's not much we can do if that's your choice"... The use case we care most about is a mass account cracking where someone changes or resets enough event registrations to disrupt attendance estimates. Given that this is entirely preventative (we haven't had this problem before, but we're evaluating our security to make sure we're doing as good a job as we can be), it'd seem reasonable to have a programmatic catch for someone logging into a bunch of accounts in succession after a bunch of failed tries with each. Further thoughts are certainly welcome, though. Adam On 11/9/09 5:06 PM, f4nt wrote: > > Yes, teaching users to not choose stupid username/password > combinations. That's the only correct/true fix. Are you worried about > the traffic that it consumes? If so, you continue to play in dicey > territory, since you're trying to deduce harmful bots from potentially > stupid users that just can't remember their account information. Yes, > it's easy to see in the aftermath with human eyes the difference, > seeing it as it happens with code, and being right 100% (which is the > only acceptable percentage in the case of usability) is difficult. > > I don't personally know if anything exists to do what you want to do, > but it shouldn't be incredibly hard to write. You could log all the > IPs to the database, compare the frequency, and then what you do with > them from there is up to you. You could redirect the user elsewhere, > or serve them 404s to make them think the content's gone (could have > ill effects on SEO in rare cases). Then you could cron up a purge > scenario, after so many days, or if you definitely don't like the IP > you could write the IPs out to your firewall's blacklist (at least, > easy to do in shorewall). Ironically, doing all that will create > potentially more database calls and traffic than just weathering the > storm. Your call. > > Btw, don't mean to be blunt/rude, as that's not my intention. Just > dealt with a lot of these scenarios as a sys admin in a former life, > and the answer is always to beat users over the head until they stop > choosing "god/god" as their username/password combination. > > On Nov 9, 3:57 pm, Adam Seering wrote: >> Hi, >> Does there exist any code for Django to help defeat brute-force >> login >> attempts? Something like blocking IP addresses from logging in if they >> try and fail too many times, etc. >> >> Adam > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Prevent brute-force password attacks?
Hi, Does there exist any code for Django to help defeat brute-force login attempts? Something like blocking IP addresses from logging in if they try and fail too many times, etc. Adam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django and PostgreSQL/Slony for load-balancing?
Hi, We're running a website that usually runs just fine on our server; but every now and then we get a big load burst (thousands of simultaneous users in an interactive Web 1.5-ish app), and our database server (PostgreSQL) just gets completely swamped. We'd like to set up some form of load-balancing. The workload is very SELECT-heavy, so this seems plausible. It looks like Slony is the recommended package for doing this. However, if we set up a Slony cluster and use pgpool to divide up queries among the nodes, the default isolation level requested by psycopg forces all the queries to go to the master database, which defeats the purpose of the cluster. If we force the system to a lower isolation level, all kinds of things start breaking, because data doesn't appear quickly enough in the slave databases, and various chunks of Django code (and our code) seem to rely on writing data and immediately reading it back. Does anyone else do this type of load-balancing? Any tips? In general, what (if anything) do folks here do for load-balancing? Thanks, Adam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
PostgreSQL Stored Procedure in ordinary Django query expression?
Hey folks,
I have a PostgreSQL stored procedure that does some fairly complex
logic to query/filter a particular table (though it ultimately does
return rows straight from that table). I'm trying to call this stored
procedure from within Django, and execute additional filters/etc on the
procedure:
MyModel.do_my_stored_procedure('proc', args).filter(mymodelfk__foo=bar)
(or the like.) Anyone have any pointers on how to best do this? Is
there, by any chance, native support for this in Django 1.1 that I just
haven't found yet?
There's an existing implementation that worked decently with Django 1.0
(djangosnippets.org #272). However, it works by generating a normal
query through an ordinary QuerySet and doing string
matching/substitution to insert the function call. I'd like to do
something a bit cleaner, but I don't yet understand Django's internals
well enough to hack them this much... Any ideas?
Thanks,
Adam
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Aggregates with multiple (conflicting) conditions?
Hey,
I have a table setup that boils down to something like the following:
class MyUser(models.Model):
type = models.IntegerField()
class MyStuffs(models.Model):
stuffs = models.ForeignKey(MyUser)
I would like to be able to do something like:
MyUser.objects.filter(mystuffs__type=1).annotate(type_one=Count('mystuffs__type')).filter(mystuffs__type=2).annotate(type_two=Count('mystuffs__type'))
ie., count the number of instances of type 1 and type 2. However, this
doesn't actually work, as the filters stack and I get zero records returned.
Is there a way around this without using custom SQL?
Adam
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Per-Test Caching?
Hi, I have a Django app that relies heavily on caching. I'd like "./manage.py test" to run on its own test cache instance (so it doesn't see keys from previous runs / other development / etc). I can write code to set up the cache appropriately, but, where can I put it s.t. it runs before (and, ideally, after, for cleanup purposes) all test cases? Adam --~--~-~--~~~---~--~~ 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: Should I set up Django locally or on a web server?
If you really want everything, then either MacPorts or Fink work well. If you just want to run through the tutorial, though, you can probably get away with the built-in version of Python and SQLite as suggested. Older Macs have Python 2.3, which should work (though it is quite old); Leopard (MacOS X 10.5) ships Python 2.5, which is the latest version. Adam On Thu, May 1, 2008 at 7:12 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Probably the most painless way to get everything you need for the > production setup is via MacPorts - apache, python, postgres, etc. > > On May 1, 2:56 pm, Kevin Monceaux <[EMAIL PROTECTED]> wrote: > > Selmac?, > > > > I've never used a Mac, so take the following with a grain of salt. > > > > On Thu, 1 May 2008, selmac wrote: > > > I know the makers of Django like postgress. Does anyone have > > > instructions for an installation of the whole package (apache, > postgres, > > > django, python, mod_python) on a mac? > > > > It sounds like at this point you just want to work through the tutorial. > > All you really need for that is Python and Django. Running Django > behind > > Apache is not recommended for testing. That's mainly for production > > environments. You can use SQLite as your database. It comes with the > > latest version of Python and would probably be the "least painless" to > use > > for testing. > > > > A little Googling indicates that Python comes pre-installed on OS X, but > > might be a bit out of date. Up to date pre-build Python packages for OS > X > > can be found at: > > > > http://PythonMac.org/packages/ > > > > Once Python is squared away, you can follow the install instruction for > > Django on the Django site and use it's built-in test web server for > > testing. > > > > Kevinhttp://www.RawFedDogs.nethttp://www.WacoAgilityGroup.org > > Bruceville, TX > > > > Si hoc legere scis nimium eruditionis habes. > > Longum iter est per praecepta, breve et efficax per exempla!!! > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
efficiently search for ManyToMany links?
Hi all, I have code that, greatly simplified, looks like the following: class CheckBoxType(models.Model): name = models.TextField() class Course(models.Model): name = models.TextField() checkboxes = models.ManyToManyField(CheckBoxType) Essentially, a Course has multiple properties (represented by a graphical Check Box image in a view); if there's a ManyToMany link between the two tables, that property for that class is Checked (so it gets the checkbox image). I'm trying to populate a matrix (== HTML ) of Course vs. CheckBoxType; essentially, for a certain subset of Courses and a certain subset of CheckBoxTypes, display all links above. I want to do this efficiently. We had previous code that checked each cell in this , and so executed len(myCourses)*len(myCheckBoxTypes) queries. This was really slow. If I could query the ManyToMany table directly, I ought to be able to do this in a single query. Is this possible in Django? What would people recommend as a solution in this case? Thanks, Adam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Database introspection dies?
Hi all,
I'm trying to introspect an old MySQL database (the old software
that used the database was written in some nasty mix of Perl and C;
it just bit the dust recently). I try an inspectdb on it, and I get
an ugly-looking stack trace. Is 'inspectdb' expected to work?; has
anyone recently used it on MySQL?
The table that it appears to get stuck on, has fields of an
autoincrement int pk, an enum, an int (used as a foreignkey to
another table), a text field, and an auto timestamp field. The final
error is "1- isn't a valid int()" (see stack trace below); there are
no "1-"'s in the table, unless the enum's feeding it one somehow
(I've no idea how to check that?). I'm assuming that means a code
bug somewhere?; is this a known bug?; anyone know if it's in Django
or MySQLdb (or should I go hunting)?
I'm running on MacOS X, with Django from svn head, and dependencies
from Fink.
Thanks,
Adam
adam$ ./manage.py inspectdb
# This is an auto-generated Django model module.
# You'll have to do the following manually to clean this up:
# * Rearrange models' order
# * Make sure each model has one field with primary_key=True
# Feel free to rename the models, but don't rename db_table values or
field names.
#
# Also note: You'll have to insert the output of 'django-admin.py
sqlinitialdata [appname]'
# into your database.
from django.db import models
class [aseering: Munged Table Name Here](models.Model):
Traceback (most recent call last):
File "./manage.py", line 11, in ?
execute_manager(settings)
File "/sw/lib/python2.4/site-packages/django/core/management.py",
line 1459, in execute_manager
execute_from_command_line(action_mapping, argv)
File "/sw/lib/python2.4/site-packages/django/core/management.py",
line 1370, in execute_from_command_line
for line in action_mapping[action]():
File "/sw/lib/python2.4/site-packages/django/core/management.py",
line 766, in inspectdb
relations = introspection_module.get_relations(cursor, table_name)
File "/sw/lib/python2.4/site-packages/django/db/backends/mysql/
introspection.py", line 30, in get_relations
my_field_dict = _name_to_index(cursor, table_name)
File "/sw/lib/python2.4/site-packages/django/db/backends/mysql/
introspection.py", line 23, in _name_to_index
return dict([(d[0], i) for i, d in enumerate
(get_table_description(cursor, table_name))])
File "/sw/lib/python2.4/site-packages/django/db/backends/mysql/
introspection.py", line 15, in get_table_description
cursor.execute("SELECT * FROM %s LIMIT 1" % quote_name(table_name))
File "/sw/lib/python2.4/site-packages/django/db/backends/util.py",
line 12, in execute
return self.cursor.execute(sql, params)
File "/sw/lib/python2.4/site-packages/django/db/backends/mysql/
base.py", line 42, in execute
return self.cursor.execute(sql, params)
File "/sw/lib/python2.4/site-packages/MySQLdb/cursors.py", line
95, in execute
return self._execute(query, args)
File "/sw/lib/python2.4/site-packages/MySQLdb/cursors.py", line
114, in _execute
self.errorhandler(self, exc, value)
File "/sw/lib/python2.4/site-packages/MySQLdb/connections.py",
line 33, in defaulterrorhandler
raise errorclass, errorvalue
ValueError: invalid literal for int(): 1-
--~--~-~--~~~---~--~~
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: User Session leakage
On Jan 18, 2007, at 9:35 AM, Jeremy Dunck wrote: On 1/17/07, Adam Seering <[EMAIL PROTECTED]> wrote: ... We're not eager to use the SVN HEAD version of source on our main servers. The Django API-change docs are good, but not that good; we have had code break unexpectedly in the past after "svn up"'s, and that just makes us sad when it happens. While I understand that reasoning, you may want to take something closer to trunk for now, and regularly have an update/test cycle in dev. 0.95 was 6 months ago, nearly 900 revs. Perhaps we should have an 0.95 bugfix branch, and backport this issue to it. This does seem to be the common practice in such frameworks; this is, after all, the purpose of a release: It's a fairly stable codebase that will be maintained for an extended period of time, with bug fixes / security patches / etc. Otherwise, you could just tell people to check out a particular SVN version, or have nightly tarballs or something. If you don't do that, I really think that Django should add a section to its download page: "This release version has a list of known security bugs.Please download patches for them." This, of course, is highly awkward. Then again, isn't distributing "release" code with known and fixed security holes, also awkward? Thanks, Adam --~--~-~--~~~---~--~~ 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: User Session leakage
On Jan 17, 2007, at 10:01 PM, James Bennett wrote: Some of the people on this project are having serious concerns about the choice to use Django for this particular project; do folks have any thoughts/answers for them? I'm not sure really what sort of answers there are to give; there aren't any silver bullets which magically make web development "safe". I agree, certainly. I understand that this sort of bug will, unfortunately, come up occasionally. Our concern is that it's been order of a thousand SVN revisions since its patch was submitted, and a version of the code with this bug is still being distributed as a major release, with no warning to new users that the code is unsafe. I've been using Django since before this security policy was posted, so I hadn't seen it; I always assumed that Django would have one additional item on the list: - Apply the patch to the downloadable distribution, at all locations where it's available, so naive new users don't get bitten by old bugs. The question really was, Is Django's policy to do this? If so, what went wrong, and are there mechanisms in place to keep it from happening again? If not, we're not sure what we will do; in terms of evaluating frameworks as we go, Django has just dropped a rather large notch in our view of things. Thanks, Adam --~--~-~--~~~---~--~~ 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: User Session leakage
Ah, ok. In [1]: from django import VERSION In [2]: VERSION Out[2]: (0, 95, None) Out of curiosity, is there a log somewhere of major security holes that are fixed since a release? And, how does one get security patches into the releases used in major distro's?; who dropped the ball on this one? We're not eager to use the SVN HEAD version of source on our main servers. The Django API-change docs are good, but not that good; we have had code break unexpectedly in the past after "svn up"'s, and that just makes us sad when it happens. On the other hand, we really don't want security issues to bite us; we're imposing in code security restrictions that exist for legal reasons, and we _really_ can't afford that kind of problem in our underlying Web framework. Some of the people on this project are having serious concerns about the choice to use Django for this particular project; do folks have any thoughts/answers for them? Thanks, Adam On Jan 17, 2007, at 4:51 PM, Jeremy Dunck wrote: On 1/17/07, Adam Seering <[EMAIL PROTECTED]> wrote: Out of curiosity, is there a way to determine the version of Django that a package uses, if it doesn't contain .svn files? django.VERSION gives a rough idea, though it's not updated between "official" releases. If you don't have django.VERSION, you're using a version prior to 0.95, I believe. > --~--~-~--~~~---~--~~ 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: User Session leakage
Hey, Applying that patch does seem to have helped on the first server; it's a probabilistic problem, but at least we haven't seen it since trying this. The first server was running Debian Etch; the second was running Gentoo. Both were using Django as installed from their local repo's (based on 0.95), not directly from SVN. Out of curiosity, is there a way to determine the version of Django that a package uses, if it doesn't contain .svn files? Thanks, Adam On Jan 17, 2007, at 11:43 AM, James Bennett wrote: > > On 1/17/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: >> Assuming the server is sane, the session cookie is the only thing >> determining the request.user, so I suspect either your server isn't >> sane (as in, threading is killing you), or something is wrong with >> downstream caches. > > Or he's using a version of Django prior to revision 3754, which fixed > a subtle bug in the way request.user is set up. Applying this diff > should clear up the problem: > > http://code.djangoproject.com/changeset/3754 > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
User Session leakage
Hi all, I've been working on a reasonably large internal site using Django. I was hitting the problem that user logins seemed to be getting confused; ie., two users logged in at the same time would occasionally switch 'User' database entries in request.user; one user's request.user would point to the other's account. This site tends to have 15-20 people on it at a time at peak usage, and page generation takes long enough that two users actually having active connections at once is quite probable. I assumed this was a bug in my code; it wouldn't be the first..., and this is a large project with too few test cases and such. However, I recently wrote another small program in Django, completely from scratch (ie. no shared codebase). This separate program also exhibited the "shared user account" problem. This other program was a small AJAX+Django chat widget, used over the course of a weekend by ~150 people; there were definitely concurrent sessions. This is getting really annoying. Anyone have any ideas on how to debug it? Thanks, Adam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Query: Follow foreignkeys?
Hi, I have two models, A and B. A.anchor is a foreignkey to B. I currently have the following code: B.objects.filter(id__in=[ x.anchor for x in A.function_that_applies_filter_to_A(data) ]) function_that_applies_filter_to_A is defined elsewhere, and I'm really not eager to change it (it's generated by about a page of rather-hairy code; it checks against several other related tables, including some minor tree-traversal in one table). It returns a QuerySet. 'data' is some processed form data from a Web POST. Is there a way to do this entirely in a single query, instead of hitting the database once, applying a filter in Python, and then hitting it again? Thanks, Adam --~--~-~--~~~---~--~~ 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: Creating an empty queryset
I would strongly second that. This seems to have fallen somewhat dead, though. Any thoughts?; anyone in favor of it?; anyone know of any reasons not to do it? Adam On Dec 27, 2006, at 1:42 PM, Adrian Holovaty wrote: > > On 12/27/06, medhat <[EMAIL PROTECTED]> wrote: >> Is there a way to create an empty queryset?! Let's say I have a >> manager >> to return all the items with the given tags, and I want to return "no >> items" if one of the given tags does not exist. Right now I return an >> empty list, but this causes an error in generic views. Is there a way >> to create an empty QuerySet object without hitting the database? > > I just had to do this the other day, and I ended up doing a hack > like this: > >MyModel.objects.extra(where=['1=0']) > > That still hits the database, though. I'm not aware of a way to get an > empty QuerySet without hitting the database. Maybe we should add one? > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > --~--~-~--~~~---~--~~ 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: Good Web development practice
On Jan 6, 2007, at 6:28 AM, [EMAIL PROTECTED] wrote: I do not really think that you need to Redirect after every post - only when data is altered. In general, I agree, but many Web browsers give an annoying warning message if you try to go back across a POST; it's nice to redirect so as to avoid that message, if you're going to a page that users may click "back" to get to. Adam --~--~-~--~~~---~--~~ 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 on REDHAT ES
On Jan 5, 2007, at 12:41 AM, [EMAIL PROTECTED] wrote: InvalidCacheBackendError: Memcached cache backend requires the 'memcache' library It sounds like you're trying to use memcached for caching. what i have installed: httpd-2.0.52 mod_python-3.1.3-5.1 postgresql-server-8.1.3-1.el4s1.2 postgresqlclient7-7.4.8-2.el4s1.1 python-2.3.4-14.3 python-devel-2.3.4-14.3 python-docs-2.3.4-14.3 python-imaging-1.1.5-1.el4.rf python-psycopg-1.1.21-1.2.el4.rf subversion-1.1.4-2.ent However, it looks like you've installed neither memcached, nor the python-memcached library. Both are available online; does installing them help? Adam --~--~-~--~~~---~--~~ 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: A basic problem with templates (I think)
Hi,
The sample string below appears correctly (ie. no "?"'s) for me; are
you saying that it does for you, or that it doesn't?
If you're just having a problem with rendered HTML: I'm not sure how
you're entering those characters, but I'm guessing that they're being
stored as Unicode characters, or at least, something outside whatever
the default charset used by HTML is. If so: Are you putting the
appropriate headers in your HTML document to tell your Web browser
that you're using Unicode, as opposed to the more-traditional ASCII?
Those escapes exist for a reason, namely, that the characters that
they represent don't normally work in an HTML file.
Adam
On Dec 28, 2006, at 9:18 AM, dutche wrote:
I don't know why, but when I write or take from the Database a word
with some kind of accent, Django shows a "?" instead. Why?? I've
changed the language in settings.py and even the TimeZone. If I escape
the chars with something like "á" it works, so isn't a problem
with my browser, right?
Does anybody knows what can be it?? I've made a simple test to see
what
the template returns, and it returns the "string" below:
t = Template("My special letters are : áéíóú")
c = Context({})
t.render(c)
'My special letters are : \xe1\xe9\xed\xf3\xfa'
print t.render(c)
My special letters are : áéíóú
Any idea?
Thanks
>
--~--~-~--~~~---~--~~
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: Get all *_set's from a model?
Hey, Thanks!; that's exactly what I was looking for, Adam On 12/13/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > On 12/12/06, Adam Seering <[EMAIL PROTECTED]> wrote: > > > > Hi, > > I know Django keeps track of connections like this somehow, for > the > > *_set properties. Is there a way to get at that information > > somehow?, or does anyone have a better idea on how to do this? > > The details you are after are all stored in the _meta member of any > object/model. For example: > > article._meta.fields is the list of normal fields, including ForeignKeys > article._meta.many_to_many is the list of m2m fields > article._meta.get_all_related_objects() returns the list of all > related objects - i.e., the objects that have a foreign key on Article > article._meta.get_all_related_many_to_many_objects() returns the list > of all related m2m objects - i.e., the objects that define an m2m > field relating to Article. > > The implementaiton of lookup_inner() in query.py gives a good idea of > how to traverse relations using members of _meta. > > Yours, > Russ Magee %-) > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Get all *_set's from a model?
Hi, I have a table (implementing a tree) that a whole lot of other tables have ForeignKeys pointing to. I'm trying to write a "clone" method that takes an element in the table, duplicates it (with a new ID), and creates duplicates of all table elements from any other tables that ForeignKey to the original table entry and re-points them at the new table entry. I know Django keeps track of connections like this somehow, for the *_set properties. Is there a way to get at that information somehow?, or does anyone have a better idea on how to do this? Thanks, Adam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Work with FileField directly
I'm trying to make a form that, among other things, allows a user to upload one or more files (the number of files will vary; it's a form to upload images that are missing on a vaguely-Wiki-like page). Each uploaded file creates a new table entry; the non-FileFields in the table are determined by other code that I've written. I expect filename conflicts to come up occasionally; I'd like for them to be dealt with automatically, like they are in the Admin interface. The web form that allows for file upload also asks for additional data; I have to handle that separately. It seems like manipulators are usually the way to handle file-upload, but how can I use manipulators to do something this complex? If I can't use manipulators, how do I deal with FileFields by hand?; just save the file myself and set "MyFileField = SavedFileName"? Is the Django function that makes a unique filename (currently by adding "_", I believe) available, or do I have to write that myself as well? Thanks, Adam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
recursive FilePathField - list file paths
I'm trying to use Django to manage a pre-existing documents directory. I'm using FilePathFields to point to files in the directory. However, the directory contains many subdirectories, and files with repeat names. The Admin interface, by default, just recursively scans directories and makes a list of all file names, not name + path. Is there a way to make the Admin interface display name + path for each file, without modifying the Django source code? If there isn't one, what are the chances that the Django maintainers would accept a patch that enabled this, if one was written? It's a feature that I need; I'd guess that others might need it, too? Adam --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
