Re: [ANNOUNCE] Django 1.6 release candidate available
Kudos for making this happen! Small discrepancy: the blog post states python 2.7 is required; the release notes it links to state python 2.6.5 is still supported, and 2.7 will be required from Django 1.7 onwards. Yishai On Wed, 23 Oct 2013 06:08:33 +0300, James Bennett wrote: It's almost here! Tonight we've issued a release candidate for Django 1.6. Information, including links to downloads and release notes, is available on the Django >project blog: https://www.djangoproject.com/weblog/2013/oct/22/16c1/ --You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/>CAL13Cg82W91nQKR_PQRBM-76AgpZxWNp6zBRsbUu0fUGJMXyfA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out. -- Using Opera's mail client: http://www.opera.com/mail/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/op.w5d8verb699m7q%40ybxps. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why apps have to have unique names? [related with subapps and name collision]
Is this not almost trivial to work around by creating a new module 'newapp', importing the original app code from it, and then using 'path.to.newapp' as a new "copy" of the app in INSTALLED_APPS? Yishai On Mon, 03 Jun 2013 12:24:38 +0300, Aymeric Augustin wrote: 2013/6/3 Jorge C. Leitão Motivated by that criticism, I want to ask: why apps have to have unique names? Hi Jorge, Django assumes that a model can be identified by (app_name, model_name). Long ago — 8 years ago — it didn't seem to be a problem. I'm not sure your research covers all the consequences of this assumption. Anything that hits the app cache depends on this assumption: - the target of foreign keys can be expressed as 'app_name.ModelName' - the fixture format identifies models with app_name.ModelName - several settings have a value in the form app_name.ModelName - django.contrib.contenttypes uses (app_name, model_name) to identify each model - since permissions are tied to content types, this assumption bleeds to django.contrib.auth - etc. Lifting the requirement of uniqueness would require switching anything that uses the app_name.ModelName format to full.path.to.app.ModelName. That would be quite disruptive, not only for Django, but for the entire ecosystem of apps, starting with contrib apps. The real question is -- what's the story for authors of pluggable apps ? for users of the framework ? As far as I know, the explanation for this behavior lies in history more than in a design decision. Until now, no one judged this to be enough of a problem to make a proposal to fix it. To be honest, it's frighteningly hard to fix. Even app-loading (ticket #3591) doesn't tackle it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proposal/Discussion: url and template search using the directory structure of apps within django sites
Hello Jorge, On Thu, 30 May 2013 12:42:20 +0300, Jorge C. Leitão wrote: Hi Russell Keith-Magee. Thanks for your criticisms. Let's see if I can answer some of them. I'd turn this question back onto you -- why *should* the search start locally? What collisions are you seeing between apps that makes a global >>search impractical? Very good question! I think this question is related with your point Well, no - I can see how you've managed to construct an example where local search might be useful (although I still don't concede that it >>couldn't be answered with global lookups). However, what I need to be convinced is to see an actual use case where this is an issue -- not a >>synthetic example, but a real world problem. I.e. in my poor example I was not able to explain myself on the reason for using local search. I'm sorry for the extension, but the reason is not so obvious. Consider the case where in a an app you have an header, with the website logo and stuff, which you want to be consistent within your website, >and you have smaller secondary header, (secondary_header.html) which you want to populate according to a specific app rendering the template. The "a specific app rendering the template" is not phrase is not well-defined. Do you mean the app (in INSTALLED_APPS) that registered the url matched for the current request? The python module where the view function sits in? The python module whence the call to the template's render() was made? The python module which loaded the template? These can all be different things. Talking about "which app" makes some sense if you're limiting yourself to URL names - but keep in mind that templates can be (and often are) used outside of an HTTP request/response cycle - what's the "app" then? One frequent option is to add a block tag and put your (appname_secondary_header.html) with the same block tag, and call the >appname_secondary_header.html in the specific's app view. This is the standard approach in Django and works great! The problem is when you try to port this app to another website which already has that appname. Then you have to change your app's name (the >directory name). However, this also means you have to change ALL the template names (or else the templates can also collide), all css, etc... you >also have to change all views that call the template. Not to mention the disaster it it if the app is within a version control... This is not solved by >adding a new folder on the templates directory with your app's name, because you would also have to change that+the all the views. This problem is exactly the same in urls. You set a url naming convention to be consistent with your app, you port the app to another site >with conflicting names and BANG. Now, the reason why this happens is because template and url names have global scope. The solution people found out to solve this issue (C/C>++, python, you name it) is to use local scope. For instance python uses namespaces, which uniquely define a name in relation to PATH or >something. In Django, namespaces are ill implemented (again, which is fine for most cases!) because they are not defined in respect to a path, they are just a >name chosen by the developer, which is susceptible to collision. In Python, packages are meant to be portable and the solution is: inside the package, you use a naming scheme assuming an arbitrary name of the >package (directory's name). If at some moment you have to change the package name to avoid collision with other package, you just have to >change the package's name and *not the content*. The names are arbitrary because the full name in relation to PATH will include the name of the >package (e.g. import package.module). So, if global scope doesn't work, what should them work? The answer (given by python developers) is local scope, and Django can use exactly >the same idea as python uses in subclassing: if you want to extend an app, you put a sub-app within that app. How would you suggest extending a 3rd party app, then? I assume you're not suggesting to place my extension inside the source tree of the 3rd party app. Python's subclassing is completely disconnected from physical paths - and you usually have to explicitly name the class you're extending - you don't inherit it simply by virtue of being in a subfolder. You also give the new, extended class a brand new name - and at least some code needs to know that name in order to instantiate the right thing. If the app extends html, then the extension is like a subclassing: your sub-app adds some functionality, while keeping other constant. In my >example of the secondary header, this means that if the sub-app has a secondary header that it would like to use, then it "overloads" the parent's >template and calls its own secondary header. It is a design decision on whether the developer
Re: Preventing the leaking of sensitive information in error logs
On Sun, 29 May 2011 15:57:34 +0300, Fraser Nevett wrote: On May 29, 5:22 am, Julien Phalip wrote: As a side thought, if this functionality does get implemented, would it be feasible/desirable to have Django emit a warning to encourage the developer to mark a view as sensitive if it detected a forms.PasswordField (or any other FormField known to handle sensitive data) being used by it? I'm not actually sure it's possible as a Form/ FormField doesn't directly know about the request, but I thought I'd throw the idea out there anyway. Perhaps something along the lines of how Django marks strings as safe / need escaping for the template engine can be applied here. A forms.PasswordField might mark its data as "sensitive", and that info would flow up until the point it is being rendered by the debug templates, printed to a log file, etc. Yishai -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: remove "Change" links on admin index page
+1 on removing it only as part of a larger admin improve/overhaul move. Is there a place where plans and ideas for such a move are discussed / aggregated? Is there any current work being done in that direction? On Mon, 23 May 2011 21:45:23 +0300, Idan Gazit wrote: I agree that it's redundant and unnecessary, but absent a particular *need* to remove it, I'd say leave it until the admin gets an overall refresh. While having two links may be marginally confusing for new users, _removing_ an existing bit of functionality is akin to a breaking change, IMO. It's not that we shouldn't do it, just that we should treat it with due gravity. If we're going to break user expectations, let's do it as part of improving the admin. The index page isn't suffering from a lack of whitespace. -I -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: EmailField max_length of 75 characters should be 256 acccording to RFC 5321
Wouldn't it be possible to work around this, even for the time being, by having auth.User read a SETTING to use as the default max_length (defaulting of course to the old 75)? Hardly the prettiest solution, but given the right name (AUTH_EMAIL_MAXLEN_HACK, anyone?) and documentation it can be made clear that this is a temporary measure. Maybe even issue a deprecation warning if used. On Thu, 05 May 2011 16:57:40 +0300, Jacob Kaplan-Moss wrote: On Thu, May 5, 2011 at 8:06 AM, Patryk Zawadzki wrote: This problem is now more severe due to Facebook returning proxied e-mail addresses in this format: apps+111.22.abcdef0123456789abcdef0123456...@proxymail.facebook.com Unfortunately, the problem of upgrading everyone's existing Django installations still prevents a core change to auth.User. If you're serious about getting the email field changed, put that effort into the work on improving/overhauling auth. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Make redirection customizable in ModelAdmin view
+1 on breaking backwards compatibility, defaulting the arg to None. However, in [1] Julien suggests to also allow a callable - which I think would be very useful, and provide all the flexibility one would need. So IMHO: - if arg is callable, call it with signature as suggested in [1] - if arg is None, use the existing default - otherwise assume it is a pre-formatted string. Yishai [1] http://code.djangoproject.com/ticket/15294#comment:6 On Wed, 04 May 2011 07:20:24 +0300, Julien Phalip wrote: On May 4, 10:59 am, Dario Ocles wrote: Hello everybody. Ramiro Morales and me were working on this ticket #15294 [0] and Julien linked this one #8001 [1]. We had a little discussion about two possible solution for #8001 and Julien suggested that we should hear your opinion (you can read all comments on ticket #15294). The discussion was about if we have to take care of backward compatibility on this issue. I uploaded two patches to #8001, one of them taking care of backward compatibility. I think that the reason for keeping backward compatibility, is just that it is good. And the reasons for deprecating the old behavior are: - Cleaner code. - This is not a documented part of Django's API, so we either can or cannot take care of backward compatibility. - I don't like to put any ugly try/catch. I'm sorry for my English. Regards, Dario Ocles (burzak). [0]http://code.djangoproject.com/ticket/15294 [1]http://code.djangoproject.com/ticket/8001 Thanks for bringing this up, Dario. I'll try to summarise here the discussion that we've had in those tickets. As part of the effort in #15294 to remove all hardcoded urls from the admin's codebase, it was suggested that the hardcoded post_url_continue parameter in the response_add method be addressed as well: def response_add(self, request, obj, post_url_continue='../%s/'): ... post_url_continue is generally used to redirect you to the new object's change page after it's been created. Since it is impossible to reverse that object's change page url if you don't know the object's model details and primary key, it was suggested that post_url_continue default to None and that the url be reversed from inside the response_add method. Now, it was also pointed out that the current use of post_url_continue was a bit limiting in that it assumes the value to be a formattable string with one format parameter (i.e. the pk). There is a backwards compatible way of dealing with this [1], and a backwards incompatible way [2]. The former first assumes that it receives a formattable string like in the "old" way, and if that generates an error then it assumes it's a pre-formatted string. The latter only assumes it's a pre-formatted string. I personally tend to prefer the latter as the implementation is cleaner and also more flexible -- it is based on the assumption that it is the developer's responsibility to provide a pre- formatted string if they want to override the default behaviour, instead of letting Django's response_add method do the formatting for you. If we go with [2] then this may be a small inconvenience for people who are relying on the current behaviour of response_add, but the upgrade path is very easy (i.e. just format the string yourself). Also, response_add is not officially documented. So, this all leads to the reason why this was brought up to the dev list: shall we go ahead and break backwards compatibility? As far as I can tell from the policy [3] we're pretty safe to go ahead, but it'd be helpful to collect more opinions on this (and if possible also more generally on the rest of the admin's codebase). Thanks a lot! Julien [1] http://code.djangoproject.com/attachment/ticket/8001/8001_redirection_backward_compatibility.diff [2] http://code.djangoproject.com/attachment/ticket/8001/8001_redirection.diff [3] http://docs.djangoproject.com/en/dev/misc/api-stability/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ignorable 404s
+1 on both: combine to regex IGNORABLE_URLS, and on empty defaults with commented-out suggestion in generated settings.py As a bonus, the transition for someone who has placed non-default values in IGNORABLE_(STARTS_ENDS) to regexes is near trivial. On Tue, 03 May 2011 23:16:12 +0300, Aymeric Augustin wrote: Hello, Currently, there are two problems with settings.IGNORABLE_404_(STARTS|ENDS): - STARTS + ENDS is too limited: for example, there's no way to exclude icon requests of iOS >= 4.2. A list of regexps would be more flexible. - The default values are fairly arbitrary and prone to endless discussion. An empty default would avoid that. Luke suggested to replace them by a single setting IGNORABLE_404_URLS here: http://code.djangoproject.com/ticket/15954#comment:2 The two old settings would be deprecated, following the usual path. In the end, that will decrement the number of settings :) That new setting would behave a lot like DISALLOWED_USER_AGENTS. I am +1 on this suggestion, what do you think? Best regards, -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: math tag
On Tue, 03 May 2011 06:59:02 +0300, Phui Hock wrote: Holy god, not to be rude, but given that this is completely unreadable I'm even more -1 than I ever would have been on the basis of the principle of a dumber template language. Alex My apologies. All that is doing is rendering the following result when the URL is http://localhost:8001/?x=2&y=3&z=4 if x = 2, y = 3, 2 + 3 = 6 if x = 2, y = 3, 2 * 3 = 6 if x = 2, y = 3, z = 4, (2^4) * (3^4) = 1296 if x = 2, y = 3, z = 4, (2 + 3) / 4 = 1 While I think there are common display issues that require a little more than the current tags, this example is the exact opposite. This is exactly the case where the math should be done in the view, never in the template. What if you want to display these calcs in a table, or in a tag? Copy the entire template over and change the tags? Cases for display logic include, off the top of my head: - substract, mainly for knowing how much width is left in some element for display (total width - sum of widths for some elements we loop through) - multiply (again, width calculations) - divide + remainder - supplements divisibleby in cases you need to know the size of the tail you're left with But I can't think of any such use for stuff like pow (^), or even complex parenthesized expressions. Yishai -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ModelForm validation - a better way?
Hi Carl,
On Fri, 29 Apr 2011 17:42:32 +0300, Carl Meyer wrote:
Hi Yishai,
On 04/29/2011 08:53 AM, Yishai Beeri wrote:
First, the logic tied into the context manager does not match the
idiomatic use of context managers in Python. One expects a context
manager to "clean up" on exit, rather than *save* a new object.
I'd argue it's not totally off base. When the action you're performing
in the context manager is "tweaking this model instance before its
saved", I think it's reasonable to consider "save it if it validates,
otherwise populate form._errors" to be appropriate and expected
"cleaning up" from that action.
For
instance, what if I throw an exception inside the with block? The idiom
tells us the object will be saved - but in this suggested approach I
probably want the opposite.
The fact that context managers imply cleanup doesn't mean that cleanup
has to be defined simplistically ("save the object no matter what"). The
context manager performs appropriate cleanup. That might be saving,
Of course, cleanup need not be simplistic. In fact, I think the common
coder would never expect a CM to actually save an object on __exit__ - and
will be surprised by the proposed behavior.
Another thing not expected by
or
populating form._errors, or (if you raise an exception inside the body)
probably neither.
I think 'neither' is also not a natural answer for what should a CM do
when exiting via an exception.
Also unclear is what happens if the form
fails validation (inside the __enter__ on form.finish); an exception?
In the original proposal there would be no form validation on __enter__,
only full validation on __exit__. The proposal could be modified to do
both - that gets into the territory of your and Johannes' alternative
proposals, which are interesting.
I agree. Perhaps saying this is a "validation" context manager, rather
than a "saving" context manager, is enough to eliminate the confusion.
That, of course, means adding an explicit form.save() call after the with
block.
...
and obviously model validation cannot rely on
per-field idioms like form validation does.
I'm not sure what you mean by this last bit - model validation and
modelform validation are actually pretty close to the same thing in the
current code (modelform validation calls model validation and catches
any ValidationErrors), with the exception of possibly excluding some
fields (and doing additional form-specific validation).
I actually referred to the difference between form validation (not
ModelForm), and Model validation. In other words, part of the validation
is mostly per-field, and usually based directly on the field definition
(be it a simple form field or one created in the modelform based on the
underlying model field); this part is more tightly related to what the
user sees and does on the form, and naturally does not need the missing
knowledge about the missing fields (or later tweaks). Another part of
validation is what I called "model validation" - everything that has to do
with the model as a whole. My thrust is that it is wise to keep them
separate (or at least easily separable).
As a very rough sketch, perhaps something along the lines of:
try:
form.validate()
obj = form.save(commit=False)
obj.user = request.user
obj.validate(form=form)
obj.save()
redirect(obj)
except FormValidationError, ModelValidationError:
redisplay the form
of course, the above can also be written with a couple of if/else
clauses, but perhaps routing validation errors as exceptions may feel
more natural in Python.
I don't really like the obj.validate(form=form) line; perhaps it needs
to be form.validate_object(obj), or even a context manager such as:
with form.validation():
form.validate()
...
obj.validate() # having the form.validation CM allows the object
validation to somehow tie the errors to the form fields, if so desired
...
This ends up being pretty similar to Johannes' idea - I'll reply to his,
feel free to note any differences you think are important.
Yes, you're right. In a nutshell:
a. keep two distinct validation phases [explicit in my suggestion,
implicit in the __enter__ and __exit__ phases of Johannes' idea]
b. allow some way for the later validation (which I called for simplicity
"model validation") to still relate to the form, hang errors on form
elements etc.
c. Make the save action (at least one that commits to the DB) explicit
[here is where my suggestion differs from both your and Johannes' ones]
It feels that for (b), a context manager of some sort is the way to go.
Adding (c) to Johannes' approach might be simply to require a call to
obj.save() after the with block
Carl
Yishai
--
You received this message because you are subscrib
Re: ModelForm validation - a better way?
Without really suggesting a better alternative, I'd like to highlight two problems I see with this approach: First, the logic tied into the context manager does not match the idiomatic use of context managers in Python. One expects a context manager to "clean up" on exit, rather than *save* a new object. For instance, what if I throw an exception inside the with block? The idiom tells us the object will be saved - but in this suggested approach I probably want the opposite. Also unclear is what happens if the form fails validation (inside the __enter__ on form.finish); an exception? Second, and this is a general issue underlying partial validation - probably part of what makes this issue so hairy - the full-model validation, and the resulting error messages, run the risk of being pretty remote from what the user actually did. It feels to me that form validation needs to be a step that focuses on values the user entered in the form, and that full-model validation should come as a second step, possibly adding more messages and tying them to particular form elements. I think in many cases the two types of validation deserve separation in code; model validation might need to be more expensive (e.g., hit the DB), and obviously model validation cannot rely on per-field idioms like form validation does. As a very rough sketch, perhaps something along the lines of: try: form.validate() obj = form.save(commit=False) obj.user = request.user obj.validate(form=form) obj.save() redirect(obj) except FormValidationError, ModelValidationError: redisplay the form of course, the above can also be written with a couple of if/else clauses, but perhaps routing validation errors as exceptions may feel more natural in Python. I don't really like the obj.validate(form=form) line; perhaps it needs to be form.validate_object(obj), or even a context manager such as: with form.validation(): form.validate() ... obj.validate() # having the form.validation CM allows the object validation to somehow tie the errors to the form fields, if so desired ... Yishai On Fri, 29 Apr 2011 05:13:31 +0300, Carl Meyer wrote: form.is_valid()? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: new backports policy
Perhaps augment the new policy by stating that contributed backports for bugs that are left out by this change will be favorably looked upon, and committed to the branch unless there is a good reason no to commit them. This still achieves the goal of making the routine bugfix commit cycle faster, but allows people that depend on stable releases to "scratch their itch", backport the important bugfixes, and get them as part of a "blessed" stable branch release. On Tue, 19 Apr 2011 22:22:26 +0300, Jacob Kaplan-Moss wrote: Hi folks -- Over the past few weeks, the core development team have been discussing how we can streamline our process to get more work done quicker. It's pretty clear that the bulk of the community wishes Django could move forward a bit faster [1], and we'd like to be able to deliver more awesomeness in less time. Ultimately, the goal will be to put out releases quicker, hit our deadlines more accurately, and be able to respond to community suggestions and patches in a more timely manner. [1] This isn't unique to Django, of course; almost every open source project wishes they could release more features more quickly. One way that we'd like to improve our speed is by modifying our existing backport policy. To refresh your memories, right now we backport any non-feature-containing patches to the previous release. So if we fix a bug on trunk, we backport the bug fix to the 1.3.X branch, where it would become part of the 1.3.1 release. This is a fair bit of work: it basically means we have to fix each bug twice. The core team has come to a rough consensus and we're planning to drop this backport-everything policy. Instead, we'll only backport critical patches. That is, we'd only backport patches for: * Security issues. * Data-loss bugs. * Crashing bugs. * Major functionality bugs in newly-introduced features. In other words, we'd basically only backport bugs that would have prevented a release in the first place. Practically, this means that if there's a minor bug in 1.3 -- for example, #15795, a bug with the representation of RegexURLPattern -- the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.* release will contain the fix, even if it's fixed in trunk. To get the fix for these bugs, users will have to upgrade to 1.4. The upside, of course, is that bug fixes will be quicker to apply, so we can fix more bugs, so we can get that 1.4 release out sooner [2]. Additionally, this'll give users more of an incentive to upgrade to the latest-and-greatest. This means that they get new features, and we (the development community) get to focus more clearly on moving forward, not maintaining older releases. [2] Look for a proposed release date soon. Spoiler alert: it's sooner than you think. We'd like to make this change effective immediately, but we also don't want to just issue this change by fiat. So we're requesting comments and feedback on this change. Do you like the idea? Why or why not? Will this policy make it more likely you'll contribute? Less likely? Thanks! Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
At the risk of bike-shedding this to death - if the current behavior included the correct message (user can't access the admin) - would we seriously consider a ticket asking to replace it with the current "misleading/more secure" message, for security's sake? On Wed, 16 Mar 2011 06:11:18 +0200, Tai Lee wrote: I also don't think it should be considered a security vulnerability to reveal that an authenticated user does not have permission to access the admin (or any other) app. If the credentials are valid and they authenticate against the defined authentication backends, then we should assume that we are talking to a trusted authenticated user and we should present error messages that are at the very least not misleading. Assuming that any authenticated user might be an attacker who has brute forced a password and presenting obscure error messages to authenticated users is not helping anybody. Cheers. Tai. On Mar 16, 3:41 am, "Brian O'Connor" wrote: 2011/3/15 Juan Pablo Martínez > The admin is not "one more app" is (if I may) the app with more weight > on most sites. Someone who has access to the admin has access to most > or all information. There is no "one more app. " This has nothing to do with the argument here. The account in question, as already stated many times, has no access to the admin site. That's the whole point of this discussion. Carelessness or neglect of a click in the admin should't call into> question the admin with the justification "that does not happen > again." This has to do with deliberately misleading users. I've been stuck by this at least once in my django career, and artemy has too. People make mistakes, it happens. > I think if everyone is going to fix "contrib" to your needs the > contrib lost all independence. I especially don't understand this statement. The whole point of django-developers is to discuss development of django, and by extension (because there are no other lists, as far as I'm aware) the contrib modules. Everyone comes here to help make the project better, to help fit their needs. That's the whole point, as far as I'm concerned. A reasonable suggestion was made, in which a few people came back and said that by doing this improvement, it would open a security issue. Myself, and others have stated that in fact, this would not be a security issue, and have provided examples. At this point, I'll absolutely never forget to check the is_staff flag purely because I've been following this discussion. What I don't understand is why there is such a huge opposition to the change. -- Brian O'Connor -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Composite primary keys
On Wed, 16 Mar 2011 07:49:17 +0200, Michal Petrucha wrote: On Tue, Mar 15, 2011 at 09:15:29PM -0500, Javier Guerra Giraldez wrote: On Tue, Mar 15, 2011 at 7:14 PM, Christophe Pettus wrote: > A concern here is that composite indexes, like unique, are > sensitive to the ordering of the fields, which means that the > ordering of the fields in the class declaration becomes important. This is the same reason a new Meta flag has been agreed upon in the past. (That, however, does not mean it has to be that way.) a simplistic proposal: the order of the fields on a composite index is determined by the exact value given to the primary_key argument. that way, just setting primary_key=True on a few fields won't guarantee order, but something like: class City (models.Model): country = models.CharField (max_length=2, primary_key=1) state = models.CharField (max_length=2, primary_key=2) city = models.CharField (max_length=3, primary_key=2) Name = models.CharField (max_length=20) would set the (country,state,city) primary key in the obvious order. in short: giving any non-falsy value to primary_key would add the field to the key, the exact value would determine ordering. I like this proposal. It might even be easier to implement than fiddling with new Meta flags and everything. One minor detail though, just setting primary_key=True on multiple fields would still have to guarantee some ordering since the primary key would be represented by a tuple. If you don't know for sure in which order the values are, you can't really use the .pk property. This feels like something that wants a named-tuple (or a full blown dict). Alternatively, provide a method on the model class that takes the name=value arguments (queryset style) and returns the right pk tuple. Otherwise, the exact ordering of the fields in the pk tuple becomes yet another implicit(!) part of the model's contract - and any code that wants to use this model will be that much more brittle. This would require a thorough explanation in the docs, that if you supply values that compare equal to primary_key, the order of fields will be the same as in the model definition. Michal Petrucha -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Wrong error message when user having is_staff=False tries to login to admin
+1 on this. Messages should not give inaccurate information. I think the current behavior is also eventually detrimental to security. In a real life setting this leads to superfluous password resets and helpdesk queries - all leading to worse password choices by the common user, besides the wasted time and effort. Obviously, the new message should only be shown if the usernamd and password are matched correctly. Yishai On Wed, 09 Mar 2011 10:39:53 +0200, artemy tregubenko wrote: Hello. I've recently reported a bug[1] in django but got advice to discuss it here on django-developers first. When a user having is_staff=False provides correct username and password to admin login page, he gets a message "Please enter a correct username and password. Note that both fields are case-sensitive." This message is wrong, because username and password are correct. Proper message should be something like "You do not have permissions to enter admin area." I want to emphasize once more that when username/password combination is wrong, message should be about wrong credentials. But when username/password combination is correct, message should be about permissions. Russellm opposed that idea saying: "This isn't a good idea, because it can be used by an attacker to identify admin accounts. This would be a leak of potentially sensitive information, narrowing the scope for any attack." I consider that point not valid for following reasons: * If attacker has no access to any login or password, he will still see "wrong password" message. * If attacker has access to login and password of one user, it won't help him to know that this user is not an admin. * If attacker knows all logins and passwords, proposed change won't make attack any easier: attacker will just try them one after another. That's why I think that proposed change doesn't weaken security and should be implemented. I'm strongly in favor of this change, because my mind was blown off when during debug I could login to a site with my credentials, but not to admin section. I've lost some time looking for a bug in my code until I checked is_staff flag. 1: http://code.djangoproject.com/ticket/15567 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On the same note, the Reports [1] page in the wiki contains several links under "Tickets by popularity", which attempt to do exactly this based on the existing CC field. However none of these links work - can anyone recall if they ever did? [1] http://code.djangoproject.com/wiki/Reports On Tue, 22 Feb 2011 16:36:10 +0200, Daniel Moisset wrote: On Tue, Feb 22, 2011 at 11:21 AM, Russell Keith-Magee wrote: This is one of those areas where we need someone to step up an volunteer to do some Trac work and show us what is possible. If http://trac-hacks.org/wiki/VotePlugin is fine for the needs, I'm ok with helping install it; although I need proper access to install it in the django trac. Same offer re #14702, given that I was the one pushing for it :) Regards, D. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On Tue, 22 Feb 2011 13:22:30 +0200, Russell Keith-Magee wrote: On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip wrote: One Trac feature that I suspect *might* help in this regard is one that I've raised before -- allowing users to flag individual issues that they have an interest in seeing solved. This isn't just another flag, because it provides a way to slice and present the data in a different way. It would allow us to provide a project-wide leaderboard of the "most wanted bugs", providing a focus for volunteer activity that doesn't currently exist. However, this requires someone to spend time developing that feature for Trac, because it isn't (to my knowledge) an out-of-the-box feature. Can't this simply be the "cc" field - or better yet a clone thereof dedicated to this "vote"? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
