Re: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.
> > Vito, I know you're trying to help, but at this point your coming > across with a strong tone of entitlement, and you're chastising us > without actually having contributed anything concrete. If you really > want to help, then contribute. > I have to agree with Jacob here (not that my opinion counts for much). The last few threads have just been a vague "Django should support new technologies", but the only concrete example was Bigtable on GAE. First, Django was included in GAE so that developers could use the templating language and views. It was never a push by Google to get Django to develop their ORM to meet the needs of their Bigtable design. Secondly, I use app-engine-patch pretty heavily now, and I think it's great. Sure, it's not in the core, and it's not the most ideal solution, but it definitely works, and I have to consider GAE a pretty niche market, to be honest. Not to mention that, from what I understand, the creators of AEP are working on some new stuff that will make the integration even more seamless. That being said, I think if you want to see a "new feature" that you must have in the Django core, going about it with the tone of "how could this not already be in the core" probably won't buy you much. Proposing potential solutions and starting relevant, well articulated discussions on the topic might get the ball rolling in that direction though. Just my $0.02. -- 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-develop...@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: Feature request - set variables in template
I think this got brought up in the forums a month or so ago, but I'd like to see a 'shortcut' for setting variables much like we have a shortcut for registering inclusion templatetags. Having to write a full fledged templatetag to set a variable is a bit much. Brian On Thu, Aug 26, 2010 at 9:22 PM, Yo-Yo Ma wrote: > I see what you're saying Russell. I myself am reluctant to use the > template tag I created in some ways. Although I cannot seem to find a > DRY way of doing what I'm doing, the idea of breaking the dogma does > bother me a bit. I thought that if I could get confirmation from the > crowds, it would make me feel better. Thanks a lot for ruining my evil > plans :) > > > On Aug 26, 6:30 pm, Russell Keith-Magee > wrote: > > On Fri, Aug 27, 2010 at 8:06 AM, Yo-Yo Ma > wrote: > > > I'm sure this will be met with criticism, but there is a reason why > > > just about all template languages allow the setting of variables. > > > > Yes. It's because most template languages are trying to be a Turing > > complete programming language. Django's template language isn't. > > > > This leads to people putting view logic in their template, and it's > > something Django's template language is specifically trying to > > prevent. In my opinion (and the historical opinion of the core team) > > this is a *feature*, not a bug. > > > > 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-develop...@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. > > -- 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-develop...@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: Inclusion of easy-thumbnails into Django Contrib
I have absolutely no pull in decision making, but maybe my message will count towards a "community voice". I think that including an image thumbnail package that integrates into the database as easily as sorl.thumbnail and easy_thumbnail are is a great idea. From what I can tell, sorl.thumbnail was the de facto standard for getting thumbnails in to Django, and I think it has just as much of a place in Django contrib as some of the other contrib apps do. I don't think it belongs in the core, but contrib seems like an excellent place for it to go along with the other batteries in the pack. On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma wrote: > I have no data to support the following assertion, but it's not too > unreasonable: More people probably need thumbnail images than they > need comments. Comments are most used on blogs, whereas thumbnails can > be used on blogs, e-commerce, photo hosting, social networking, > project management, et al. It's not to say that we don't need > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > On Sep 15, 11:32 pm, "David P. Novakovic" > wrote: > > Actually, that really did sound negative. Sorry :) > > > > Is there a trac ticket open to address this issue? Generally it'd be > > better to get discussion happening over a ticket and if there are > > serious issues that need to be addressed then they can be discussed > > here. > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > django.contrib , but the truth is that this probably falls outside of > > things that that should be in contrib. Contrib isn't really an easier > > way to get stuff into django, it still has to satisfy a bunch of > > conditions like the rest of the code in the core. > > > > The real question is not "can it be included?" but why is it a problem > > that this is a third party lib at the moment? Is there a strong case > > that it be better if it was part of django core or does it do its job > > just fine the way it is now? > > > > David > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > wrote: > > > I don't want to sound negative, but answering your own question before > > > anyone else can doesn't change the answer ;) > > > > > D > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma > wrote: > > >> Is there any plans to incorporatehttp:// > github.com/SmileyChris/easy-thumbnails/ > > >> into django.contrib? I have seen so many apps/libraries come into and > > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor > > >> instance mentions sorl-thumbnails which is no longer being developed). > > >> I just turned the key with easy-thumbnails and voila. It's like magic, > > >> but not. It's easy enough to see what's going on behind the scenes. > > > > >> This is something that, with the help of the core and other > > >> contributors, could be really great. It works for me as it it is, but > > >> it may not work for a more "enterprise" application that uses S3, etc. > > >> It might not be highly efficient (I wouldn't know). It might have bugs > > >> that I just haven't noticed yet. I'm mentioning all of this because I > > >> know somebody will say, "Why move it into Django if it's doing just > > >> fine as a separate project?". After experiencing the bliss I thought > > >> I'd drop a line here about it, and see what you guys thought. > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups "Django developers" group. > > >> To post to this group, send email to > django-develop...@googlegroups.com. > > >> To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > > >> For more options, visit this group athttp:// > 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-develop...@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. > > -- 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-develop...@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: Inclusion of easy-thumbnails into Django Contrib
Yeah, I'm aware, that's why I said '_was_ the de facto standard' :) easy-thumbnails is what I had in mind when I was agreeing with you. I think it's a great piece of software that satisfies most people's needs for image manipulation within a web development environment, and being in contrib will allow people to use another package if they don't like it. On Thu, Sep 16, 2010 at 12:37 PM, Yo-Yo Ma wrote: > sorl-thumbnails is over. The two developers who were maintaining it > have started to different projects. One relies on ImageMagik and is > probably not as easy for the crowds. The other is "easy-thumbnails". > > On Sep 16, 10:33 am, "Brian O'Connor" wrote: > > I have absolutely no pull in decision making, but maybe my message will > > count towards a "community voice". > > > > I think that including an image thumbnail package that integrates into > the > > database as easily as sorl.thumbnail and easy_thumbnail are is a great > > idea. From what I can tell, sorl.thumbnail was the de facto standard for > > getting thumbnails in to Django, and I think it has just as much of a > place > > in Django contrib as some of the other contrib apps do. I don't think it > > belongs in the core, but contrib seems like an excellent place for it to > go > > along with the other batteries in the pack. > > > > > > > > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma > wrote: > > > I have no data to support the following assertion, but it's not too > > > unreasonable: More people probably need thumbnail images than they > > > need comments. Comments are most used on blogs, whereas thumbnails can > > > be used on blogs, e-commerce, photo hosting, social networking, > > > project management, et al. It's not to say that we don't need > > > "contrib.comments", just that I wouldn't want to lose easy_thumbnails. > > > > > On Sep 15, 11:32 pm, "David P. Novakovic" > > > wrote: > > > > Actually, that really did sound negative. Sorry :) > > > > > > Is there a trac ticket open to address this issue? Generally it'd be > > > > better to get discussion happening over a ticket and if there are > > > > serious issues that need to be addressed then they can be discussed > > > > here. > > > > > > I know it'd be nice to get things like easy-thumbnails accepted into > > > > django.contrib , but the truth is that this probably falls outside of > > > > things that that should be in contrib. Contrib isn't really an easier > > > > way to get stuff into django, it still has to satisfy a bunch of > > > > conditions like the rest of the code in the core. > > > > > > The real question is not "can it be included?" but why is it a > problem > > > > that this is a third party lib at the moment? Is there a strong case > > > > that it be better if it was part of django core or does it do its job > > > > just fine the way it is now? > > > > > > David > > > > > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic > > > > > > wrote: > > > > > I don't want to sound negative, but answering your own question > before > > > > > anyone else can doesn't change the answer ;) > > > > > > > D > > > > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma < > baxterstock...@gmail.com> > > > wrote: > > > > >> Is there any plans to incorporatehttp:// > > > github.com/SmileyChris/easy-thumbnails/ > > > > >> into django.contrib? I have seen so many apps/libraries come into > and > > > > >> go out of existence ( > http://code.djangoproject.com/wiki/ThumbNailsfor > > > > >> instance mentions sorl-thumbnails which is no longer being > developed). > > > > >> I just turned the key with easy-thumbnails and voila. It's like > magic, > > > > >> but not. It's easy enough to see what's going on behind the > scenes. > > > > > > >> This is something that, with the help of the core and other > > > > >> contributors, could be really great. It works for me as it it is, > but > > > > >> it may not work for a more "enterprise" application that uses S3, > etc. > > > > >> It might not be highly efficient (I wouldn't know). It might have > bugs > > > > >> that I
Re: Enabling context access in simple_tag
> > As an example of what I'm talking about -- #14262 is a manifestation > of a use case that is undeniably simple: "get_function() as var". This > pattern is used in several places in Django's own codebase. To that end, I'm willing to be practical and concede that adding takes_context > would at the very least be consistent, even if it still fails to hit a > large range of test cases. Forgive me if this proposal has already been turned down, but what about the following: We give takes_context to the simple_tag shortcut, for consistency. Then a new shortcut, assignment_tag is added such as @register.assignment_tag def get_foobars(): // do work return results Then, within the template, the user simply calls `get_foobars as coconuts`, `results` gets assigned to `coconuts` within the context. There is also the broader (and completely nebulous) > proposal regarding making tag parsers easier to write. That's a *much* > bigger can of worms. Personally, I don't think writing a template tag is _too hard_. I think it's overkill for the simple tasks, namely assigning content to a variable. If we had a shortcut to do that, anything beyond that could be done as a regular custom tag. (sorry if this was formatted horribly, I was battling with gmail here). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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/11 Juan Pablo MartÃnez > That's fine. Why give more information than necessary? > You can not enter and that's it. > This is not an error because it is done so on purpose. > Less is more. > -3 This is not an issue of 'giving more information than necessary'. This is about giving information that is not misleading to users. If I were to read that message, I would think I had a typo in my login information, not that I didn't have access. If you don't have access, the message should say 'This is not a valid administrator account.' or something akin to that. I'd like to see this fixed as well. -- 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
> If an attacker is brute forcing logins, providing a nondescript error > message here makes life harder. > > That claim doesn't really make sense to me. There's 1 of 2 scenarios in my mind, but I've been wrong before and I'll be wrong many more times in my life. Scenario 1: The site has an open login system where there are regular users and admin users (is_staff=True). If an attacker wants to brute force this type of site, they'll simply use the regular public facing login mechanism, verify account credentials and then use them on the admin facing login screen. Get an error, you know they're not an admin. Scenario 2: The site only has admin users, and there are no _active_ users with is_staff=False. At first it might seem like providing a non-descriptive error message would stop an attacker from brute forcing this type of account. However, there are _only_ admin users on this site. There will be no active users who would have is_staff=False, and therefore any time an attacker got hold of valid credentials, they would be entered into the admin area. The only logical thought I can see here is that if there are inactive users in the database, you allow the attacker to stop their attack short when they find the a user with invalid permissions, and go to the next account. This doesn't seem like enough benefit to justify having a confusing message presented to legitimate users, at least in my opinion. -- 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
> > 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
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.
