Re: A New Design for the "Congratulations!" Page

[Babatunde Akinyanmi]

I also give a big +1 to this. I'll really love to see this in django

On 19 Apr 2017 11:05, "Adam Johnson"  wrote:

> A massive +1 from me too, but I'll not make any comments on design :)
>
> On 19 April 2017 at 09:58, Federico Capoano 
> wrote:
>
>> Looks like a great improvement for newcomers! I hope to see this included
>> to Django.
>>
>> Federico
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/cdff13ec-bf9e-406e-addf-ec2c78b2a8bd%
>> 40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAMyDDM0vXAj0p3YZZbmOhCwa4G4%
> 3Dm9xA1pgtLFuhxC7do%3DmEHQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BWjgXOypFP-cokOaK9mmYZJPZ8%3DbdvvMkUUUXEt3wHdnWtT1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improvement to objects.get_or_create and objects.update_or_create

[Babatunde Akinyanmi]

On 27 Aug 2014 22:19, "Benjamin Scherrey"  wrote:
>

>
> You're right, it wasn't hard to implement as external code as I've
already done so. The main reason why I propose it for inclusion into
Django's codebase is because the new behavior is actually what I would have
expected these two functions to do and, so far, individuals that I've
polled said the same thing. When they discover what the generated SQL
actually looks like they're quite surprised.
>

+1.

I agree on the 2 points. I'm not expert enough to comment on the backwards
compatibility though.

>
> -- Ben
>
>
> On Thu, Aug 28, 2014 at 3:55 AM, Marc Tamlyn 
wrote:
>>
>> This would be fairly significantly backwards incompatible, and any
heuristic based code I think belongs in user space.
>>
>> It should not be too problematic to write as an external module, if it
gains a lot of traction we can reconsider.
>>
>> Worth also noting that the json implementation in contrib.postgres is
being delayed until at least postgres 9.4 and will use the jsonb data type
which does have an equality operator.
>>
>>
>> On 27 August 2014 21:04, Benjamin Scherrey  wrote:
>>>
>>> Apologies for the cross-post. I imagine this is actually where this
proposal belongs. Would anyone be interested in getting an implementation
of this for consideration for incorporation into some upcoming or back
ported release of Django?
>>>
>>>   -- Ben Scherrey
>>>
>>> -- Forwarded message --
>>> From: Benjamin Scherrey 
>>> Date: Mon, Aug 25, 2014 at 4:58 PM
>>> Subject: Improvement to objects.get_or_create and
objects.update_or_create
>>> To: django-users 
>>>
>>>
>>> Just want to run an idea by the list for a feature improvement for the
oft-used convenience functions get_or_create and update_or_create. I'll
just talk about get_or_create for now on but everything I saw going forward
applies to both.
>>>
>>> It's a common idiom to populate a dictionary and simply pass it
straight on to the function when creating or updating objects. While
get_or_create takes a named parameter, defaults, as the content to
store/update and the normal parameters are used for both search and
content. The problem is that quite often you just have a dictionary of
content you want to throw into the model table and don't want to separate
it out into search content vs. default content. If you don't separate it
out you get a big nasty where clause on the select that tries to compare
every bit of content for the item.
>>>
>>> For the most part this behavior is just a nuisance and probably
sub-optimal db query. However, with the new json data type it will actually
cause the code to break as you can't pass in a json structure as a search
value in a where clause. Your app will break.
>>>
>>> My proposal, which I've written in my own code, is to have
get_or_create automatically select the most appropriate data to use for the
search clause and then to make the rest "default" data to be applied to the
found or newly created object. It first tries to see if the primary key
field is present in the data structure. If that's not found then it goes
through the model fields and looks for any field designated as unique in
the data structure. The result is a cleaner and faster SQL request and a
prevention of the above mentioned error condition. If no primary key or
unique field is present in the data structure then behavior will continue
as currently implemented.
>>>
>>> Is this a change that would be welcome in the django project? If so I'd
 be happy to create a pull request that implements this policy and
supporting unit test coverage.
>>>
>>> thanx,
>>>
>>>   -- Ben
>>>
>>> --
>>> Chief Systems Architect Proteus Technologies
>>> Chief Fan Biggest Fan Productions
>>> Personal blog where I am not your demographic.
>>>
>>> This email intended solely for those who have received it. If you have
received this email by accident - well lucky you!!
>>>
>>> --
>>> 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/CAHN%3D9D5-9GyYAKVn4j0xB7tvvDtUtYFFMrUxc2UxPm%3DvgebA3w%40mail.gmail.com
.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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://gro

Re: [GSoC] Switching to Jinja2 proposal

[Babatunde Akinyanmi]

On 15 Feb 2014 18:13, "Donald Stufft"  wrote:
>
>
> On Feb 15, 2014, at 11:43 AM, Christopher Medrela 
wrote:
>
>> My last post was pretty long and the most important questions and
statements
>> have left unanswered, so I will repeat them.
>>
>> What I'm proposing now is more conservative proposal. Firstly, Django
will
>> support Jinja2 out-of-the-box, but DTL will remain the "blessed" option.
>> Secondly, Django will allow to mix DTL and Jinja2 templates (so you can
>> include/inherit DTL template from Jinja2 one and vice versa).
>>
>> After doing it, I could focus on 3) decoupling DTL or/and 4) rewriting
Django
>> builtin templates in Jinja2 or/and 5) moving rendering form widgets from
>> Python code to Jinja2 templates.
>>
>> After that all, we could start again the war DTL vs Jinja2, but please
focus
>> on the new proposal now.
>>
>> Questions are:
>>
>> 1) What do you think about the new proposal? Would it be useful?
>>
>> 2) Jinja2 doesn't support 3.2. Will Django 1.8 support 3.2?
>>
>> 3) Supporting Jinja2 out-of-the-box means introducing dependencies. Are
we
>>ready for this?
>
>
> If we have Jinja2 I don't see any reason to keep the DTL as the blessed
option.

Exactly
>
>>
>> On Tuesday, February 11, 2014 2:07:19 PM UTC+1, Aymeric Augustin wrote:
>>>
>>> 2014-02-11 13:42 GMT+01:00 Christopher Medrela :
>>>

 What did Armin said about Python 3 exactly?
>>>
>>>
>>> He wrote an extensive argumentation about "why Python 2 [is] the better
>>> language for dealing with text and bytes" [1] as well as a number of
tweets
>>> and a few other blog posts along the same lines.
>>>
>>> While his arguments are technically correct, I disagree with his
conclusions
>>> because he's speaking with the point of view of an expert maintaining
>>> libraries at the boundary between unicode and bytes (like werkzeug).
However,
>>> most Python users aren't experts and aren't maintaining such libraries.
In my
>>> experience working with Python programmers ranging from intern to
veteran, the
>>> unicode model of Python 3 is a strict improvement over Python 2 in
terms of
>>> pitfalls hit in day-to-day programming. YMMV.
>>>
>>> [1] http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
>>>
>>> --
>>> Aymeric.
>>
>>
>> OK, so Armin finds Python 2 better than Python 3. But why is it at odds
with
>> Django? He didn't say that he is not going to support Python 3. So where
is
>> the risk that concerns you?
>>
>> --
>> 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/79dbbf71-6b70-48d1-8510-cef471812677%40googlegroups.com
.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>

-- 
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/CA%2BWjgXOegMcvFC4_%2Bg8-siy_2s_VqLg5ecYquO4rw8_ivmBNzw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

RE: Proposal: Redefine specific {% block %} in an intermediate

[Babatunde Akinyanmi]

 template
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

+1 for being confusing

Sent from my Windows Phone
From: Carl Meyer
Sent: 4/17/2013 5:37 PM
To: django-developers@googlegroups.com
Subject: Re: Proposal: Redefine specific {% block %} in an intermediate
template
Hi Emil,

On 04/17/2013 09:50 AM, Emil Stenstr=C3=B6m wrote:
> Proposal:
> Make it possible to use the same template block name twice, if the
> second one is nested within the first one. Inheriting from the template
> fills in the innermost block.

This is an interesting proposal, but I am concerned that the syntax you
propose is confusing on several levels:

1) If I haven't seen this done before, and I'm reading your template and
I see the two nested blocks, it's not at all intuitively obvious that
child templates would override the inner one rather than the outer one.
In fact, my naive assumption would have been the opposite.

2) If the "warning" HTML in your example is lengthy, I may see the outer
block and not immediately notice the inner one, and be confused as to
why the child templates aren't overriding the "content" block I can see
right in front of me.

I also think you missed the best (existing) solution to your example
problem:

> --
> Background (why is this useful?):
> Say you have one base.html template defining a {% block content %}, and
> ten templates inheriting from it and defining the contents of the block.
> Now you decide that five of those templates actually should have a
> warning message at the top, and you decide to make a new
> base_with_warning.html template. You should should now be able to just
> change what block five of the templates inherit from, add the warning to
> your new base template, and be done with it?
>=20
> Not really. Your base_with_warning.html would have to look like this:
>=20
> {% extends "base.html" %}
> {% block content %}
> Be careful when changing these settings!
> {% block content %}{% endblock %}
> {% endblock %}
>=20
> And this doesn't work in Django because duplicate block names are not
> allowed. I think making this possible would make cases like the one I'm
> describing above much easier to handle.
>=20
> --
> Alternatives (this is how you should solve it instead...):
> There are other ways to solve the problem I'm describing above. Let me
> list a few and talk about the problems I see with them:
>=20
> 1) Create a new template block in base_with_warning.html and change the
> five templates to use that block instead.
>=20
> Problem: This puts the burden on developers to remember all kinds of
> content blocks they have in this project, and change them depending on
> what template they happen to be inherit from. The interface to the
> developer working on a new child template is much cleaner if they know
> they can always use the content block, and that the template they
> inherit from with handle the rest.

Why not instead add a new block to base.html? So you'd change base.html
to have:

{% block outer-content %}
{% block content %}{% endblock content %}
{% endblock outer-content %}

And base_with_warning.html:

{% extends "base.html" %}

{% block outer-content %}
...
{% block content %}{% endblock content %}
{% endblock outer-content %}

I think this achieves your goal that none of the inheriting templates
have to change anything besides which template they extend. And it does
it with very little added verbosity in the base templates, a clearer
conceptual layering of blocks, and less potential for confusion when
reading the templates.

> 2) Make a child templates call super, and put the warning div inside the
> content block in base_with_warning.html.
>=20
> Problem: It's very easy to forget calling super when making a new
> template. It quickly becomes repetitive to type block.super in each of
> the templates. Should I call super in the five templates without a
> warning too? Just to be sure it isn't forgotten if someone changes the
> inherited template.
>=20
> 3) Use an include tag in each of the child templates instead of inheritin=
g.
>=20
> Problem: This is just as repetitive as copy-pasting the div to each of
> the subtemplate, it's just the {% include "warning.html" %} is a shorter
> string to copy-paste. As with all copy-paste, it makes it easy miss one
> instance when changing the others. Not maintainable.
>=20
> 4) Use a template variable to decide whether to render the warning or not=
.
>=20
> Problem: This moves the copy-paste to the view logic. Now I need to
> remember to pass the right variable in the view instead, with the same
> problem as with copy-paste above.
>=20
> 5) Write a custom template tag that does what I want.
>=20
> Problem: I really don't know how to do this, and I haven't found someone
> that has written a tag like that after are plenty of googling.

I agree that none of these solutions are good.

Carl

--=20
You received this message because you are 

RE: Ability to save 4xx messages to database

[Babatunde Akinyanmi]

Hi Javier, why no

Sent from my Windows Phone
From: Javier Guerra Giraldez
Sent: 4/11/2013 4:30 PM
To: django-developers@googlegroups.com
Subject: Re: Ability to save 4xx messages to database
On Thu, Apr 11, 2013 at 10:21 AM, Val Neekman  wrote:
> Now, the $64 K question: is Django a good place for this?

I'd say no.  the best place would be a monitoring system.

a surprisingly good approach is to use rsyslog protocol, and add a
good event storage backend to the centralizing rsyslogd. i've seen
some examples of using Redis to store these.


--
Javier

-- 
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.

-- 
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: deprecate and remove django.contrib.comments

[Babatunde Akinyanmi]

+1

Sent from my Windows Phone
From: Jacob Kaplan-Moss
Sent: 3/7/2013 5:48 PM
To: django-developers
Subject: Proposal: deprecate and remove django.contrib.comments
Hi folks --

This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases.

My rationale is this: if you don't really care much about how comments
work but just want something easy, then Disqus (and its competitors)
are easier to use and have much better features (spam prevents,
moderation, etc.). If you want something complex and specific, on the
other hand, you're better off writing something from scratch.

Practically, I'd do this by deprecating `django.contrib.comments` in
1.6. We'd immediately stop making any changes to it (except for
security or data loss issues). It'd stay deprecated in 1.7, and would
be removed in 1.8.

If someone volunteers to maintain it as an external project I'll move
the code to a new repo and direct people there in the docs. If nobody
volunteers, then it'll go to the great /dev/null in the sky.

Any objections?

Jacob

-- 
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.

-- 
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: Django performance vs others

[Babatunde Akinyanmi]

That was so long I can't even remember what I read.

On 10/4/12, Jacob Kaplan-Moss  wrote:
> Hey folks --
>
> This thread's pretty off-topic for django-dev. Can you please take it
> elsewhere? Thanks.
>
> Jacob
>
> On Thu, Oct 4, 2012 at 12:49 PM, Amirouche Boubekki
>  wrote:
>>> Are the Hello world applications are strictly the same (sessions, auth
>>> etc) ?
>>
>>
>> The code is available on bitbucket. They are simple hello word apps, a
>> view
>> which returns a «Hello World» string as body response.
>>
>>> I still can't see why people wast so much time in such biased "Hello
>>> world" tests to claim a definitive "X is the fastest Python web
>>> Framework."
>>
>>
>> I still can't understand why people wast so much time claiming the work
>> of
>> others is useless because you actually mean useless, isn't it ?
>>
>>
>>> Database optimization, ORM, API quality, documentation, libraries,
>>> security.
>>
>>
>> I take for granted that at least you have some notions of what makes a
>> good
>> Web framework. But, Is there any verb that I should guess to make it
>> possible to build conversation about this statement ? In particular, what
>> do
>> you mean by API quality, because that is a particular area I'd like to
>> improve.
>>
>>> Does your framework allow users to deliver in a limited time ? That is
>>> the
>>> true question.
>>
>>
>> Huhu! I think you are refering to the old line «Web framework for
>> perfectionnist with deadlines» which was well translated in french and
>> with
>> a formulation which can stands time and projects as «Web framework for
>> perfectionnist in a hurry». It was maybe a legit claim 7 years ago
>> (almost
>> ten and two hundreds years at the Web scale) because all solutions at
>> that
>> time were bloated, broken, not as cool or simply not as good as Django,
>> but
>> today is almost 2013. Don't expect people to sit down and wait for Django
>> to
>> leave 1.0 branch to rework the template engine, get rid of managers,
>> provide
>> a framework for asynchronous tasks that implements ack and doesn't try to
>> delete faulty tasks because they expired, reconsider what can be done in
>> Django to make the life of frontend developpers easier regarding the
>> pervasive use of Javascript clients, provide a framework for service
>> oriented applications, take into consideration multiple user editing in
>> the
>> admin, multiple databases transactions if doesn't already, make it work
>> on
>> Python 3, make the admin even more hack-friendly, validate/testify any
>> other
>> useful apps that are nowdays taken for standards in webdev and be simply
>> better at what it does already well, I agree, and start eating market
>> shares
>> of self proclaimed entreprise solutions™. Otherwise said, simply impress
>> me
>> again and stands out or consider the fact that today Django is just like
>> any
>> other Python Web framework, no more, no less, with a good documentation
>> and
>> numerous zealots. It maybe be superflus to look for speed when there is
>> other more useful/important/sexy work to do, but it might also not be
>> possible to do this improvement without forking or starting from scratch.
>>
>> The project you are talking about got its fair number of critisism on
>> Python
>> ML thread already. Do you think this guy is stupid? He was simply
>> starting
>> to market his work with a simple benchmark no more, no less, and I'd bet
>> it
>> perform well on full applications too. Most probably he was hacking in
>> his
>> garage with an idea, getting a Python framework out and make it as good
>> as
>> Django and maybe better. And according to the numbers we have now it is,
>> according the the template syntax it is (or you like to write parsers in
>> Python), according the well crafted and separated repositories it is
>> (maybe
>> a personal preference I agree). You can take for granted that this
>> framework
>> doesn't have an admin area yet, and couldn't make the mistake of
>> recomputing
>> most urls for every request, making it useless for any user-facing
>> private
>> area of reasonable scale, yay, there are top notch admin projects out
>> there
>> that integrate recognized html5 frameworks of today, but I agree this is
>> a
>> minor issue for people ready do write some code instead of sneaking into
>> the
>> admin. According to you not only this guy may be stupid, but his work
>> might
>> be useless. Maybe you do not know what competition is ? Or, you don't
>> know
>> what free and open source software is ? It looks like the latter is true
>> at
>> least contributing code doesn't seem to be part of your agenda or maybe
>> your
>> are too much concerned about putting down the work of others and making
>> zillions out of the work of some. But I guess you are just venting and
>> not
>> improving the discussion at all. Most probably because you cannot do «un
>> pouillème» of what this guy did and of what I hope he will do, you are
>> well
>> behind this guy in terms of contributions not only fo

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

[Babatunde Akinyanmi]

I like this feature and have recently been thinking of implementing
such on my own myself.
+1 for the feature request.

On 9/27/12, Dan Loewenherz  wrote:
> Hey all!
>
> This is a feature request / proposal (one which I'm willing to build out,
> given that I've already developed a solution for my own uploader).
>
> I run a consulting business that helps small startups build initial MVPs.
> When the time ultimately comes to deciding how to store static assets, my
> preference (as is that of many others) is to use Amazon S3, with Amazon
> CloudFront acting as a CDN to the appropriate buckets. For the purposes of
> this ticket, s/S3/your object storage of choice/g.
>
> Now, Django has an awesome mechanism for making sure static assets are up
> on S3. With the appropriate static storage backend, running ./manage.py
> collectstatic just searches through your static media folders and copies
> the files.
>
> The problem I've run into is that collectstatic copies all files,
> regardless of whether they already exist on the destination. Uploading
> 5-10MB of files is pretty wasteful (and time consuming) when none of the
> files have changed and no new files have been added.
>
> As I wrote in the trac ticket
> (https://code.djangoproject.com/ticket/19021),
> my current solution was to write a management command that does essentially
> the same thing that collectstatic does. But, there are a few differences.
> Here's a rundown (copied straight from the trac ticket).
>
> I currently solve this problem by creating a file containing metadata of
>> all the static media at the root of the destination. This file is a JSON
>> object that contains file paths as keys and checksum as values. When an
>> upload is started, the uploader checks to see if the file path exists as
>> a
>> key in the dictionary. If it does, it checks to see if the checksums have
>> changed. If they haven't changed, the uploader skips the file. At the end
>> of the upload, the checksum file is updated on the destination.
>
>
> I'll contribute the patch. I know there is not a lot of time before the
> feature freeze, but I'm willing to make this happen if there's interest.
>
> If we don't want to change behavior, perhaps adding a flag such as
> --skip-unchanged-files to the collectstatic command is the way to go?
>
> All the best,
> Dan
>
> --
> 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.
>
>

-- 
Sent from my mobile device

-- 
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: Django is not a serious framework, really

[Babatunde Akinyanmi]

I wonder why you guys are replying OP.

On 4/11/12, Juan Pablo Martínez  wrote:
> gooby pls :)
>
> On Wed, Apr 11, 2012 at 10:29 AM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hi Jason,
>>
>> Le 11 avril 2012 14:10, Jason Ma  a écrit :
>> > I heavily doubted that whether the writers have tested that carefully.
>>
>> As one of the many people who replayed the tutorial from A to Z,
>> checked every little detail, updated screenshots, etc. before the
>> release of 1.4, I feel your feedback is rather unfair.
>>
>> > There are many people saying the Django is well-documented, do you
>> > still think  it is true?
>>
>> Django's documentation assumes that the reader:
>> - has some familiarity with Python (e.g. knows what a __init__.py or a
>> *.pyc file is)
>> - is an autodidact and is able to investigate by himself when (s)he
>> deviates from the recommended path and encounters an unexpected
>> behavior (e.g. syncdb doesn't perform migrations).
>>
>> Honestly, if this doesn't match your expectations at all, then Django
>> might not be the right framework for you.
>>
>> I still believe our documentation compares favorably to most
>> open-source software entirely developed by volunteers in their free
>> time.
>>
>> Best regards,
>>
>> --
>> Aymeric.
>>
>> --
>> 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.
>
>

-- 
Sent from my mobile device

-- 
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: Don't assume that missing fields from POST data are equal to an empty string value.

[Babatunde Akinyanmi]

-1
I think a programmer should not specify a field that would contain
important data as optional in the first place. If the data loss from
not including it in the form is going to cause problems then it should
not be optional.

On 1/11/12, Tai Lee  wrote:
> There is a potential for data loss with optional form fields that are
> (for whatever reason) omitted from an HTML template.
>
> For example, if we take an existing model form and template that
> works, add an optional character field to the model but fail to add a
> corresponding field to the HTML template (e.g. human error, forgot
> about a template, didn't tell the template author to make a change,
> didn't realise a change needed to be made to a template), when that
> form is submitted Django will assume that the user has provided an
> empty string value for the missing field and save that to the model,
> erasing any existing value. This is not a bug, but it is relatively
> easy to trigger silent and unexpected data loss.
>
> I have briefly discussed this with PaulM and dstufft on django-dev,
> but could did not reach any consensus.
>
> RFC1866 [1] says:
>
>> The fields are listed in the order they appear in the
>> document with the name separated from the value by `=' and
>> the pairs separated from each other by `&'. Fields with null
>> values may be omitted. In particular, unselected radio
>> buttons and checkboxes should not appear in the encoded
>> data, but hidden fields with VALUE attributes present
>> should.
>
> The HTML4 spec at W3C.org [2] says:
>
>> Users interact with forms through named controls.
>>
>> A control's "control name" is given by its name attribute. The scope of
>> the
>> name attribute for a control within a FORM element is the FORM element.
>>
>> Each control has both an initial value and a current value, both of which
>> are
>> character strings. Please consult the definition of each control for
>> information about initial values and possible constraints on values
>> imposed by
>> the control. In general, a control's "initial value" may be specified with
>> the
>> control element's value attribute. However, the initial value of a
>> TEXTAREA
>> element is given by its contents, and the initial value of an OBJECT
>> element
>> in a form is determined by the object implementation (i.e., it lies
>> outside
>> the scope of this specification).
>>
>> The control's "current value" is first set to the initial value.
>> Thereafter,
>> the control's current value may be modified through user interaction and
>> scripts.
>>
>> A control's initial value does not change. Thus, when a form is reset,
>> each
>> control's current value is reset to its initial value. If a control does
>> not
>> have an initial value, the effect of a form reset on that control is
>> undefined.
>>
>> When a form is submitted for processing, some controls have their name
>> paired
>> with their current value and these pairs are submitted with the form.
>> Those
>> controls for which name/value pairs are submitted are called successful
>> controls.
>
> as well as [3]:
>
>> A successful control is "valid" for submission. Every successful control
>> has
>> its control name paired with its current value as part of the submitted
>> form
>> data set. A successful control must be defined within a FORM element and
>> must
>> have a control name.
>>
>> However:
>>
>> * Controls that are disabled cannot be successful.
>> * If a form contains more than one submit button, only the activated
>> submit
>>   button is successful.
>> * All "on" checkboxes may be successful.
>> * For radio buttons that share the same value of the name attribute, only
>> the
>>   "on" radio button may be successful.
>> * For menus, the control name is provided by a SELECT element and values
>> are
>>   provided by OPTION elements. Only selected options may be successful.
>> When
>>   no options are selected, the control is not successful and neither the
>> name
>>   nor any values are submitted to the server when the form is submitted.
>> * The current value of a file select is a list of one or more file names.
>> Upon
>>   submission of the form, the contents of each file are submitted with the
>>   rest of the form data. The file contents are packaged according to the
>>   form's content type.
>> * The current value of an object control is determined by the object's
>>   implementation.
>>
>> If a control doesn't have a current value when the form is submitted, user
>> agents are not required to treat it as a successful control.
>>
>> Furthermore, user agents should not consider the following controls
>> successful:
>>
>> * Reset buttons.
>> * OBJECT elements whose declare attribute has been set.
>>
>> Hidden controls and controls that are not rendered because of style sheet
>> settings may still be successful.
>
> I interpret the above to mean that any text input with a value
> attribute (even `value=""`) is successful control, and should be
> included in the encoded form data. This is wh

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Babatunde Akinyanmi]

+1 please

On 9/29/11, Wim Feijen  wrote:
> Hello,
>
> Would it be a good idea to write a ticket and patch to stop brute
> force attacks, either by requiring people to fill in a captcha after
> several failed login attempts; or by setting a time delay?
>
> Mozilla Secure Coding Guidelines recommend in doing so, see:
> https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Easy_Quick_Wins
>
> Google uses a captcha and I favor that approach.
>
> Would it be a good idea to create a ticket for this, and write a
> patch?
>
> Best regards,
>
> Wim
>
> ---
>
> From the Mozilla Secure Coding Guidelines:
>
> Account Lockout and Failed Login
> Account Lockouts vs login failures should be evaluated based on the
> application. In either case, the application should be able to
> determine if the password being used is the same one over and over, or
> a different password being used which would indicate an attack.
>
> The error message for both cases should be generic such as:
>
> Invalid login attempts (for any reason) should return the generic
> error message
>
>  The username or password you entered is not valid
>
> Logging will be critical for these events as they will feed up into
> our security event system and we can then take action based on these
> events. The application should also take action. Example would be in
> the case that the user is being attacked, the application should stop
> and/or slow down that user progress by either presenting a captcha or
> by doing a time delay for that IP address. Captcha's should be used in
> all cases when a limit of failed attempts has been reached.
>
> --
> 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.
>
>

-- 
Sent from my mobile device

-- 
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: please reopen ticket 15567

[Babatunde Akinyanmi]

The correct approach is to give a "one size fits all" error message.
While security is important, so also is user experience.

On 9/13/11, Adam Jenkins  wrote:
> On Tue, Sep 13, 2011 at 12:42 PM, Wim Feijen  wrote:
>> Hi, thanks for your quick responses!
>>
>> Flavio, Jan and Florian, it only "gives away information" when an
>> attacker guesses both the username and the password right.
>
> I think this is the correct approach. Give them the access warning on
> correct login. It also seems to be the standard way to doing such
> things in my experience.
>
>>
>> But if he can guess those right, he could already access the users
>> information using the normal login! So giving this message does not
>> change the danger. On the other hand, it would prevent lots of
>> confusion.
>
> We really shouldn't be confusing the end user. It's just bad design to do
> so.
>
>>
>> But we are repeating arguments here, so could you please read:
>>
>> http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef
>>
>> before responding?
>>
>> Thanks!
>>
>> Wim
>>
>>
>> On 13 sep, 19:23, Flávio Amieiro  wrote:
>>> On Tue, Sep 13, 2011 at 2:16 PM, Cal Leeming [Simplicity Media Ltd]
>>>
>>>  wrote:
>>> > +1, if the user/pass is entered, that user is entitled so know what its
>>> > own
>>> > permissions are.
>>> > The error should give "You have insufficient access to this page" or
>>> > something like that.
>>>
>>> The thing is: if someone does a brute force attack on '/admin/' and
>>> gets this message back, they know there's a user with that
>>> login/password in the system. Since brute force attacks using common
>>> login/password pairs in this kinds of urls is so common, I think this
>>> exposes your user more than necessary.
>>>
>>> -1
>>
>> --
>> 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.
>
>

-- 
Sent from my mobile device

-- 
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: please reopen ticket 15567

[Babatunde Akinyanmi]

+1 again.
If a correct username and password combination are given, the person
submitting the credentials should know that he doesn't have access
just like cal pointed out. Its unfair and frustrating to say that the
combination is wrong

On 9/13/11, Cal Leeming [Simplicity Media Ltd]
 wrote:
> +1, if the user/pass is entered, that user is entitled so know what its own
> permissions are.
>
> The error should give "You have insufficient access to this page" or
> something like that.
>
> Cal
>
> On Tue, Sep 13, 2011 at 6:12 PM, Florian Apolloner
> wrote:
>
>> -1, This would leak information about the users (But I am sure that's
>> discussed at length in the other threads)
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/django-developers/-/5iy7pazGNGkJ.
>>
>> 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.
>
>

-- 
Sent from my mobile device

-- 
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: please reopen ticket 15567

[Babatunde Akinyanmi]

+1

On 9/13/11, Wim Feijen  wrote:
> Hello,
>
> When a user tries to login on the admin, with correct username &
> password, but is_staff is set to False, the error message is
> misleadingly wrong:
>
> "Please enter a correct username and password. Note that both fields
> are case-sensitive."
>
> Ticket 15567 deals with this and is currently marked as wont fix.
> After a lenghty discussion on
>
> http://groups.google.com/group/django-developers/browse_thread/thread/df19241a0b1a04ef
>
> the general consensus seems in favor of changing the error message and
> thus to re-open the ticket.
>
> Could the ticket please be reopened?
>
> Thanks,
>
> Wim
>
> Ticket 15567:
> https://code.djangoproject.com/ticket/15567
>
> A patch:
> https://code.djangoproject.com/attachment/ticket/16834/admin_not_allowed.diff
>
> --
> 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.
>
>

-- 
Sent from my mobile device

-- 
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: CSRF token not validated?

[Babatunde Akinyanmi]

+1

On 9/12/11, Carl Meyer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Jens,
>
> On 09/12/2011 10:20 AM, Jens Diemer wrote:
>>
>> I wonder that the CSRF token send from the client didn't be validated.
>
> Well, it is sanitized to only alphanumeric characters, but you're right
> that the length is never checked.
>
>> Don't know if a DOS attack is possible by sending many request with very
>> long CSRF tokens?
>>
>> IMHO it's a good idea to check the length before do anything with it.
>
> Sanity-checking the length sounds reasonable to me - do you mind opening
> a ticket for this and attaching your patch?
>
> Thanks,
>
> Carl
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk5ubHQACgkQ8W4rlRKtE2frrQCgr8HhCPKaPGKyTocUGnmiU9Ku
> ekYAoNgZqJ/n4SJnd1tD2Zkpeb/+du47
> =ZWv6
> -END PGP SIGNATURE-
>
> --
> 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.
>
>

-- 
Sent from my mobile device

-- 
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.