Re: Proposal: template-based widget rendering
Hi Bruno, On 03/14/2011 06:33 PM, Bruno Renié wrote: > Although Django 1.3 is not released yet I'd like to take advantage of > the pycon sprints to discuss a proposal for 1.4: render form widgets > using Django templates instead of python code. > > This approach is implemented in django-floppyforms [0] (I'm the > author): each widget gets a template_name argument, and the render > method of each widget renders this template. Floppyforms also provides > hooks to inject data in the template context, making it quite easy to > implement custom widgets: add some context data, define a custom > template and you're done. > > This approach has a couple of advantages and drawbacks. > > Advantages: > > - Templates give you escaping for free, giving us better protection against > XSS > - Template authors can alter widget rendering more easily > - This would also fix the "how do I specify my own doctype?" issue: > Django can provide XHTML-style elements and people can switch > to html4-style s by providing their own set of templates. > > Drawbacks: > > - Template rendering is slower than string interpolation. There is a > benchmark in the floppyforms source tree, for a simple form the > rendering takes 9 milliseconds instead of 1.5 milliseconds. With > template caching enabled, it drops to 3 milliseconds. It still takes > no time but I can see it being an issue. > - We need to add a template loader to provide the default form > templates without asking the users to add 'django.forms' to their > INSTALLED_APPS. > > Backwards-compatibility is not going to be a big issue: the default > templates can implement django's current behaviour. > > We've been discussing it with Jannis and Carl and I'm trying to start > a broader discussion. A side-effect of such a change would be to make > the widgets API public and provide hooks for customization. In > floppyforms I've been trying to follow the same conventions as the > class-based views, using template_name and get_context_data as > extension points. > > I'm happy to work on the patch and convert the admin widgets but I'd > like to hear people's voices about: > > 1) If such a change is desired, and how we can make it faster, > 2) how the API should differ from floppyforms, > 3) make sure no significant use case is forgotten. As we've already discussed here at PyCon, I'm +1 on this change. It makes forms far more flexible and usable by template authors, and I think that will benefit almost all Django users. It's more consistent with Django's philosophy that presentation issues should be accessible to template designers who are not necessarily Python programmers. There is the speed tradeoff, and I sure hate to do anything that we know is slower. But I feel like this is a case of "do it right, then make it fast" - and I just think this is clearly the right way to do it. Probably the right way to make it fast is to make the template engine fast (Alex Gaynor had some interesting proposals for that for last year's GSoC, though it got dropped in favor of the no-SQL stuff). In absolute terms, I think the speed difference is already small enough that only a small fraction of users will be impacted by it, and they would always have the option to replace the default widgets in their forms with their own faster versions. The auto-escaping is another significant advantage - it's quite easy to forget to escape something that should be escaped in a custom widget (we had such a bug in Django itself until the latest security release), and I think it can only be good for security to discourage people ever building HTML strings in Python code. I already use floppyforms on all projects, and don't have any issues with the widget API it provides. > This could be part of a broader change related to form rendering (e.g. > fieldsets, looping over fields, etc) but I haven't thought about this > enough to have a concrete proposal. For more information, see that > discussion that happened at Djangocon: > > https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas Although these proposals are related, and will involve some similar changes (i.e. the need to be able to load default form templates), I think the broader questions about form-rendering tags still need more work, and converting the built-in widgets to use templates doesn't need to be delayed while we hammer all of that out. Carl -- 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: Expensive queryset cloning
Hi Alex, On 03/14/2011 08:49 PM, Alexander Schepanovski wrote: > Personally, I would like all querysets mutate not clone by default. > And when one need a clone just make it explicitly. This is not an option. It will break quite a lot of existing code, and often in highly confusing ways. You'll need to find other ways to optimize. I'd be surprised if the cloning of querysets is actually a significant bottleneck relative to the database query itself, unless you're doing loops with hundreds or thousands of clones, in which case it can almost certainly be optimized via Q objects. If you really think it will make a significant difference for your app, you can probably achieve this for yourself by using your own subclass of QuerySet and overriding the _clone method. Carl -- 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: Ticket 14261 - add basic clickjacking protection to Django
Luke - I suggest taking a look at the patch, as it works exactly as you describe (i.e. CSRF-like). Only thing that's not in there is having the middleware in the project template but commented out. I can add that in too. -- 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.
Ticket #15610 : Generic Foreign Keys break when used with multi-db.
http://code.djangoproject.com/ticket/15610 I just stumbled upon this unusual and problematic behavior, and thought that it might be worth a discussion. Details are in the ticket. Regards, Ed Gutierrez -- 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.
Composite primary keys
Good evening (or whatever it is in everyone's timezone). I'm an undergrad computer science student at the Faculty of Mathematics, Physics and Informatics, Commenius University, Bratislava, Slovakia and I'm willing to participate in this year's GSoc. I'm interested in fixing the six-year-old open ticket in trac concerning the subject, http://code.djangoproject.com/ticket/373 Before I dig deeper into the issue I would like to know whether there is interest in having this fixed and whether it is worth a full GSoC project. Also, is there already any work regarding this issue underway? If so, would it be reasonable for me to go on with this project? Anyway, if I'm to take on the task, there are quite a few design considerations to be taken care of. For starters, I've read through David Cramer's work on this from two-three years ago. I'd stick to the API skeleton that was agreed on back then, however, there remain lots of other unresolved questions. The following list is in no way meant to be exhaustive, it's just a list of things that came to my mind during the past hour. In fact, I'd appreciate other issues that would need to be kept in mind I forgot to mention. - The composite primary key would be specified as a tuple of strings in a primary_key attribute inside a model's Meta class instead of having a field with primary_key=True. - The pk property of model instances would be a tuple instead of a single value for composite key models. - The admin could reference composite keys using some kind of smart string escaping, for example escaping the , (comma) and using it as a delimiter. - This could maybe even be used in generic relations. Is it reasonable to support this in generic relations? The following post suggests it might not be the best idea: http://groups.google.com/group/django-developers/msg/dea0e360c6cd37a6 - The managers and querysets would have to be updated to handle composite primary keys correctly. - Consequently, there would need to be added support in the SQL compiler. - The same holds for syncdb, inspectdb would be also nice. - ForeignKeys would have to be backed by multiple database columns. How should they be named by default? How should their names be overriden? Should db_column expect a tuple of strings? Should there be another db_column_prefix option to prefix the names with a common string? - What about the ForeignKey field's attname? Should it be a tuple of names or should it be a single string pointing to a tuple of attributes? - How should a person trying to add a ForeignKey field pointing to its own model into the primary_key be punished? - Does it make sense to make a subset of columns created by a ForeignKey part of a primary key? - The forms framework would need a way to pass composite ForeignKeys as parameters. - What about OneToOne? Some items in this list are my ideas on how to implement something, some are things already decided during previous attempts, others are questions which I believe are not entirely up to me to decide on. I'll be grateful for any comments on any of these points and as I said earlier, any other considerations related to the topic. Also, these would somehow have to be split into two parts: those to be focused on from the perspective of this project and those to be postponed to a later stage or with little relevance. Thanks in advance for any feedback. Michal Petrucha signature.asc Description: Digital signature
Expensive queryset cloning
I was optimizing my django app and ran into this. My app was spending
too much time cloning querysets. I looked into code but didn't find
any simple way to make it faster. But this is not needed actually. In
most use cases "a parent" of a clone is thrown out. So usually one
just need to mutate queryset not clone it.
For example:
Item.objects.filter(category=12).exclude(visible=False).order_by('-
date')[:20]
clones 4 times and 0 is needed. Using Q objects we can reduce it to 3
(still too much) and complicate the code.
Even
Item.objects.get(pk=2)
clones 2 times.
Personally, I would like all querysets mutate not clone by default.
And when one need a clone just make it explicitly.
--
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.
Proposal: template-based widget rendering
Hi django devs, Although Django 1.3 is not released yet I'd like to take advantage of the pycon sprints to discuss a proposal for 1.4: render form widgets using Django templates instead of python code. This approach is implemented in django-floppyforms [0] (I'm the author): each widget gets a template_name argument, and the render method of each widget renders this template. Floppyforms also provides hooks to inject data in the template context, making it quite easy to implement custom widgets: add some context data, define a custom template and you're done. This approach has a couple of advantages and drawbacks. Advantages: - Templates give you escaping for free, giving us better protection against XSS - Template authors can alter widget rendering more easily - This would also fix the "how do I specify my own doctype?" issue: Django can provide XHTML-style elements and people can switch to html4-style s by providing their own set of templates. Drawbacks: - Template rendering is slower than string interpolation. There is a benchmark in the floppyforms source tree, for a simple form the rendering takes 9 milliseconds instead of 1.5 milliseconds. With template caching enabled, it drops to 3 milliseconds. It still takes no time but I can see it being an issue. - We need to add a template loader to provide the default form templates without asking the users to add 'django.forms' to their INSTALLED_APPS. Backwards-compatibility is not going to be a big issue: the default templates can implement django's current behaviour. We've been discussing it with Jannis and Carl and I'm trying to start a broader discussion. A side-effect of such a change would be to make the widgets API public and provide hooks for customization. In floppyforms I've been trying to follow the same conventions as the class-based views, using template_name and get_context_data as extension points. I'm happy to work on the patch and convert the admin widgets but I'd like to hear people's voices about: 1) If such a change is desired, and how we can make it faster, 2) how the API should differ from floppyforms, 3) make sure no significant use case is forgotten. This could be part of a broader change related to form rendering (e.g. fieldsets, looping over fields, etc) but I haven't thought about this enough to have a concrete proposal. For more information, see that discussion that happened at Djangocon: https://github.com/SmileyChris/django-forms/wiki/Django-form-API-ideas Regards, Bruno [0] https://github.com/brutasse/django-floppyforms -- 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: Default project layout / directory structure
On Fri, Mar 11, 2011 at 1:14 PM, Simon Litchfield wrote: > Who votes we should come up with a django-blessed 'official' default project > layout / directory structure? Sure -- no disagreement that it would be good to have some common ground with regards to project layout. All we need now is to agree what that blessed project layout should be. :-) And there's the rub. There are a bunch of people with different ideas. For example, take one idea in your list: virtualenv and pip. For many, this won't be even slightly controversial. But for others, it will be a complete show-stopper, because there is many a site that enforces a 'package manager only' approach to system adminstration. So, we have to tread carefully here. At some level, we may just need to make an executive BDFL call. However, a BDFL isn't going to make a call until there is a proposal (or three) on the table. What we need is for someone to drive the discussion and make this happen so that we are in a position to actually bless something. For the record, this isn't a new idea, either. Django's tutorial has said "more coming soon" for as long as I've been involved with Django. At several times over the last couple of years, there have been discussions about adding step 5, 6 and more. One of the ideas that is kicking around is to talk more about project structure, showing how a reusable app fits into the picture; how pip, virtualenv, tools like fabric and chef fit into the picture; and so on. However, writing tutorials takes time, and writing good tutorials takes longer. So -- if you build it, they will come. Someone just needs to build it :-) Yours, Russ Magee %-) -- 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: Ticket 14261 - add basic clickjacking protection to Django
On 14/03/11 20:38, Paul McMillan wrote: However, I also agree with Ryan N that this should be off by default. If it must be on, it should use SAMEORIGIN (as the patch currently provides) to avoid breaking existing sites. I would suggest putting the middleware in the project template, but leaving it commented out with an explanation, like the admin is done. This will help people become aware of it, and make it very easy for people who need it to turn it on. I would prefer an approach that was more selective. In particular, this header (usually) only makes sense in the context of a page which contains a form. If we must enable it by default, we should limit it to those pages. I don't think this is a practical requirement. We would have to inspect the HTML before adding the header, which adds lots of complications for things like for streaming responses, and we really don't want to be making that harder. It also doesn't work in the context of pages that build forms via javascript in some way, and neither does it cater for the very common case of pages that allow actions to be taken without any forms at all e.g. AJAX. It is impossible to examine a page and see whether it is potentially dangerous or not. However, to make it more selective, I would suggest something like the CSRF approach - a middleware that can be turned on globally to allow for quick, blanket protection, then decorators that: - turn off the global protection (something like 'clickjack_exempt') - add the protection, whether or not the middleware is present (something like 'clickjack_protect'). If anyone has better ideas for how to implement this pattern which has now come up a few times (i.e. the need for easy global protection, with more fine grained options available), I'd be really interested to hear. Regards, Luke -- Evolution (n): A hypothetical process whereby infinitely improbable events occur with alarming frequency, order arises from chaos, and no one is given credit. Luke Plant || http://lukeplant.me.uk/ -- 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
On Mon, 2011-03-14 at 15:57 +, Tom Evans wrote: > This is one of my bug-bears with the current authentication system - > it has no concept of role. The current action when an identified user > visits the admin site is to display a login form, which is totally > wrong in my opinion. The user has already presented credentials, which > we have accepted, so why should we expect them to have another > different set of credentials? > > Similarly, most restricted access views are currently protected by the > login_required decorator. Again, this is pretty good, but it doesn't > solve the authorization issue. With the vast majority of views I > decorate with @login_required, I actually need three states: > > Unidentified -> login page > Identified, but no access -> homepage, with error message > Identified, access -> allow through Spot on, IMO - it's muddling authentication and authorization up together. The user is authenticated, and shouldn't be arbitrarily given the impression that they're not when they try to access a page to which they don't have access. There's nothing "special" about the admin here, except that it is provided as part of the "batteries included". How does your site respond when a user tried to access any other URL to which they are denied access? Whatever happens there is probably what should happen when they try to access the admin. It could be a 403, a redirect to homepage, a forced logout with disabling of account and email to admin, could be all sorts of things, depending on the site. The question should probably be "how can we allow the developer to specify the desired behaviour when the user attempts to access a URL to which they have no access?" - subject to the usual provision of sensible defaults etc. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- 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: Ticket 14261 - add basic clickjacking protection to Django
I agree that Django should include this functionality in core. The header is a very useful way to discourage click-jacking in modern browsers. However, I also agree with Ryan N that this should be off by default. If it must be on, it should use SAMEORIGIN (as the patch currently provides) to avoid breaking existing sites. For better or worse, frames are an integral part of the web today. Taking a stance as an entire framework that by default, content should not be framed, is a _very bad_ choice. Many sites use Django to build open data platforms, and many of the interesting sites on the web today function as mashups of other site content (often by framing it, often without an explicit "go-ahead" by the framed site). If we force every site creator to explicitly enable the ability to be framed, we are directly creating a closed, less dynamic, less interesting internet. I would prefer an approach that was more selective. In particular, this header (usually) only makes sense in the context of a page which contains a form. If we must enable it by default, we should limit it to those pages. -Paul -- 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: Need experts to develop for you? Try Bixly
Hi Vana -- This sort of thing is utterly unacceptable here. This is a technical group dedicated to discussions of Django itself, not end-user stuff and certainly not personal promotion. What you posted is really almost spam, and if you've spent any time around technical folk at all you'll know how we feel about spammers. I think you owe this group an apology for the noise, but that's up to you. What's up to me is to enforce the standards here, and you've been warned. Don't ever do this again. 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: Default project layout / directory structure
Check out django-startproject from lincolnloop.com https://github.com/lincolnloop/django-startproject Kill off all the server configs (though some of it might be cool, like Fabric integration), and I think it'd make for a pretty good base to work from if this were to go into core. On Mar 13, 9:17 pm, John Debs wrote: > I like the idea too, since I've run into a lot of situations where > some more convention here would make a decision much easier to make. > However, it isn't clear what exactly should be better defined and I > think the first step to a serious proposal would be to figure that > out. > > The only example that comes to mind is Pinax's apps/ directory for a > project's internal apps – it's a good convention that many people > already follow. My other gripe has already been taken care of, with > the integration of django-staticfiles. > > What other things did you have in mind? -- 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: #14733: A vote in favor of no validation of .raw() queries
On Mar 12, 2011, at 12:56 PM, Jacob Kaplan-Moss wrote: > Christophe, can you write a patch including a new warning to put in the docs? All set: http://code.djangoproject.com/ticket/14733 -- -- Christophe Pettus x...@thebuild.com -- 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.
Need experts to develop for you? Try Bixly
CEO of Bixly, Adam Temple, has learned something you probably already know – it’s puzzling to find a company that has both high quality and economic. Finding just one of those qualities in a company isn’t very difficult. A group that is both? This is essentially where Bixly is positioned. Paying for the quality your project deserves doesn’t have to break the bank Here at Bixly, we specialize in writing Python/Django code for our clients. That's all we do. Since our startup in 2008, we have seen tremendous growth year over year. We are still small however, and take very good care of our clients. If you haven't introduced yourself, pick up the phone and we your current needs and our past projects. You can check us out at http://bixly.com and see what we're all about. Our rates are also posted on the website. Vana Moua Senior Consultant email: v...@bixly.com Website: http://bixly.com Skype #: (559) 761-0588 Office #: (877) 673-7059 Want to learn more about Django? Here's a link you can watch: http://www.youtube.com/watch?v=ZqYxML3_coc -- 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
> > Which might be a valid concern if your public-facing login interface > highly protected, but your admin interface is not (for example, > because it's only available on your protected intranet). Sure, it's > the edgiest of edge cases and if you care enough, you should have > applied the same security measures in the first place. So yes, this > most likely is not a security issue at all. > > If your admin site is on a protected intranet, are we really trying to protect against a brute force attack? -- 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: Wrong error message when user having is_staff=False tries to login to admin
OTOH, I don't see a valid usage scenario not involving an admin who
has 2 accounts in the system and forgot which one was the proper one.
PS. If you're really concerned about messages from admin you should be
really outraged by _("Your e-mail address is not your username. Try
'%s' instead.") % user.username
That example is bad, but not misleading. Message about wrong credentials
is misleading. It misled me to waste whole hour figuring out what's wrong
with my login system - that's a usage scenario I want to fix.
Scenario: developer uses django to create a site, has is_staff=False for
some reason, django actively prevents debugging that issue.
--
arty ( http://arty.name )
--
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
On 14 March 2011 17:14, Rohit Sethi wrote:
> To re-iterate, you would get this message iff you have the correct
> credentials for an end user who is not an admin user. You seem to be
> referring to Response Information Discrepancy Information Exposure
> (http://cwe.mitre.org/data/definitions/204.html) which is generally
> about differentiating between incorrect user-name versus incorrect
> password. The security benefit here is negligible since the only
> scenario it protects against is when an attacker who can access the
> admin interface is either unaware or unwilling to try the same attack
> on the end user interface.
Which might be a valid concern if your public-facing login interface
highly protected, but your admin interface is not (for example,
because it's only available on your protected intranet). Sure, it's
the edgiest of edge cases and if you care enough, you should have
applied the same security measures in the first place. So yes, this
most likely is not a security issue at all.
OTOH, I don't see a valid usage scenario not involving an admin who
has 2 accounts in the system and forgot which one was the proper one.
Now we can bikeshed to all eternity that the message is wrong (it's a
bit right too - you didn't gave valid creditials for this site. The
fact that your main site and admin site use the same user base is an
implementation detail), but that won't help anyone.
Anyway, Django 1.3 add an option to change the auth form used by
admin[1], so changing that message isn't that hard now. Another option
I already mentioned is adding extra help text in the template (you can
even make it display only if the form is invalid).
[1]:
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.login_form
PS. If you're really concerned about messages from admin you should be
really outraged by _("Your e-mail address is not your username. Try
'%s' instead.") % user.username
--
Łukasz Rekucki
--
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
To re-iterate, you would get this message iff you have the correct credentials for an end user who is not an admin user. You seem to be referring to Response Information Discrepancy Information Exposure (http://cwe.mitre.org/data/definitions/204.html) which is generally about differentiating between incorrect user-name versus incorrect password. The security benefit here is negligible since the only scenario it protects against is when an attacker who can access the admin interface is either unaware or unwilling to try the same attack on the end user interface. On Mar 14, 11:09 am, Juan Pablo Martínez wrote: > I dont think so. > If I dont know the username and password I > can also try username and password and wait for the system > to send another different error message. then I get valid credentials. > > 2011/3/14 artemy tregubenko > > > is visible only -- 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
2011/3/14 Juan Pablo Martínez : > I dont think so. > If I dont know the username and password I > can also try username and password and wait for the system > to send another different error message. then I get valid credentials. This is one of my bug-bears with the current authentication system - it has no concept of role. The current action when an identified user visits the admin site is to display a login form, which is totally wrong in my opinion. The user has already presented credentials, which we have accepted, so why should we expect them to have another different set of credentials? Similarly, most restricted access views are currently protected by the login_required decorator. Again, this is pretty good, but it doesn't solve the authorization issue. With the vast majority of views I decorate with @login_required, I actually need three states: Unidentified -> login page Identified, but no access -> homepage, with error message Identified, access -> allow through >From the AAA, Django currently only really provides Authentication (auth) and Access Controls (permissions). It doesn't really provide any mechanism for Authorization. In my projects, we have utilized _ExtendedCheckLogin (the class from which @login_required is built around in 1.2 IIRC) to provide @user_passes_test decorator, which takes a lambda function which is called with the current user, and @logged_in_permission_required, which is a specialization of @user_passes_test that simply takes a permission name. So, why am I jabbering about AAA, when this is about correctness of an error message on the admin site? Well, the two dovetail quite nicely. Imagine that django has this full AAA support. The admin views are no longer decorated with @login_required, since they require a lot more than that. Instead, they look something like this: @user_passes_test(lambda u: u.is_staff or u.is_superuser) def index(request): ... Now this whole argument is moot. If the logged in user does not have access to the admin site, they are sent to the homepage with a message explaining that they don't have access. If they aren't logged in, they get sent to the login page in order to do so. We now never have to confuse our users by showing a logged in user a login form. Now lets examine the extra information we may be leaking to an attacker: If the site has both admin login, and regular login, then there is no additional risk; an attacker detecting that a user account exists and that they have the right credentials for that user by detecting a change in error message from logging into a protected resource that the user does not have access to is no different than an attacker confirming an account exists and they have the right credentials by actually logging into the account in the main interface. If the site only has admin login, then the attacker would be able to determine that there is a user account with these credentials. However, this would be credentials for a user who cannot themselves log into the site, making them of limited usefulness. I hope this wasn't too long to read! Cheers Tom -- 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
I dont think so. If I dont know the username and password I can also try username and password and wait for the system to send another different error message. then I get valid credentials. 2011/3/14 artemy tregubenko > is visible only -- 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
Again: this change does not compromise security, because it's effect is visible only *after* security is compromised: when attacker has valid username and password for the site. I understand that the "correct" message is another, but I do not see why it has to amend the current when the change is more vulnerable end up leaving the system. To me what should be discussed now is not whether to put the correct message or not (because that is "correct "), you should discuss whether to allow changes made in some way, compromise security. -- arty ( http://arty.name ) -- 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
I understand that the "correct" message is another, but I do not see why it has to amend the current when the change is more vulnerable end up leaving the system. To me what should be discussed now is not whether to put the correct message or not (because that is "correct "), you should discuss whether to allow changes made in some way, compromise security. On 13/03/2011, Rohit Sethi wrote: > To summarize - if I understand correctly the only way a more specific > error message can result in a problem is the following scenario: > 1) An attacker correctly guesses credentials for a user on the admin > site > 2) The attacker does not try to authenticate with the same credentials > on the regular site > > The attacker is able to determine that the credentials are correct AND > the user is *not* an administrator. This is only a risk if #2 holds, > which leads to me believe it's a very low risk scenario. You could > argue there's some incremental security benefit in withholding > information, but I'm not sure it justifies the hit to usability. > > My primary job is to help prevent security vulnerabilities, but I'd > still say +1 for giving a more specific message in this context. > > On Mar 13, 10:41 am, TiNo wrote: >> +1 for giving a correct message. It has bitten me more than once, and I >> really don't think it would make any attack harder. >> >> The information you would give is the same information that can be >> acquired >> by logging in to the main site first, and then trying to log in to the >> admin >> site. So at the moment we are trying to obscure something that isn't >> obscure >> now either... >> >> >> >> >> >> >> >> On Sat, Mar 12, 2011 at 13:35, Peter wrote: >> > I think some people seem to be confused about what is being asked for. >> >> > I think the suggestion is that you should get this new "not an admin >> > account" message iff >> > the provided username _and_ password are correct. If you don't have >> > permission, but >> > provide an incorrect password, then you still get the old message. >> >> > That way, you can only gain more information than with the current >> > system when you have >> > both a username and correct password. If an attacker has that >> > information, then frankly, >> > it's too late to be thinking about how to make things more secure. >> >> > Regards, >> >> > Peter >> >> > -- >> > 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. > > -- > 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. > > -- :: juanpex -- 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.
template-caching: fragment name as variable
before adding a new ticket I just wanted to discuss this issue:
when using template-caching it´s sometimes useful to have a variable for the
"fragement name".
e.g., I want to prefix all caching-variables with "myapp_userid", because I
need to delete alle user-related caching-variables at some point where I
don´t have the necessary caching-variables (besides the user-id).
so, instead of writing:
{% cache 500 "fragment_name" request.user.id other_vars %}
I´d like to have
{% cache 500 "fragment_name_including_user_id" other_vars %}
I just hacked the templatetag "cache" and it seems to be quite easy using a
context-variable for the fragment name.
{% cache 500 "fragment_name" cache_var %}
{% cache 500 fragment_var cache_var %}
what do you think?
regards,
patrick
--
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.
