Re: Time based one time password and django ?

[Gavin Wahl]

I have a project that implements TOTP and U2F as a third-party 
package: https://github.com/gavinwahl/django-u2f

On Sunday, January 15, 2017 at 3:47:56 AM UTC-7, ludovic coues wrote:
>
> Hello, 
>
> After reading the recent thread on authentification in django, I 
> wondered about the chance of getting a 2-step auth mechanism in 
> django.contrib. 
>
> Time based one time password, or TOTP, is now part of the RFC 6238. 
> For those who don't know it, it use a shared secret and current time 
> to produce 6 digit number. That number change every 30 seconds and is 
> used to confirm login after entering a correct username and password. 
>
> As far as I can tell, there is no such thing present in django 
> currently. But I don't know if it's because nobody have done the  work 
> or if there are reason to not include 2-step solution in django. 
>
> -- 
>
> Cordialement, Coues Ludovic 
> +336 148 743 42 
>

-- 
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/7a3b3837-5c24-4984-abb8-d68d9ce31459%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

[Gavin Wahl]

I don't think any abstraction is possible. Postgres has 8 different
table-level locking modes, in addition to advisory locks and 4 row-level
lock modes. I would say any attempt to abstract that would remove
functionality, and that would not be convenient.

We are already suffering from an over-abstraction of locking -- we have
limited support for SELECT ... FOR UPDATE, but not SELECT ... FOR SHARE
(not to mention FOR NO KEY UPDATE and FOR KEY SHARE, which to be honest
probably aren't useful to call from an ORM). QuerySet.select_for_update has
an option to enable NO WAIT, but not SKIP LOCKED.

-- 
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/CACPudh0KQ4XW-2G71ZDx__g6AmUO5v6QDF7zWPdCAj_1Gnjeag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Table Locks and bulk creating inherited models

[Gavin Wahl]

> with MyModel.objects.lock():
> ... do stuff ... 

This is misleading as it implies the lock is released when the context 
manager exists, but in postgres at least the lock will be held until the 
end of the transaction.

What advantage does implementing an ORM API for table locking have over 
`cursor.execute("LOCK TABLE mymodel")`?

-- 
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/0fdb1d35-3a08-4095-a40e-0aaed462f6dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal on Custom Indexes - Google Summer of Code

[Gavin Wahl]

Would you be able to support partial indexes as well?

On Tuesday, March 8, 2016 at 7:46:02 AM UTC-7, akki wrote:
>
> Hi
>
> My name is Akshesh Doshi (akki). I am a student at Indian Institute Of 
> Technology, Roorkee (IITR). I have been contributing to Django 
>  for quite some time now and 
> my experience has been really great till now. I found the community to be 
> very welcoming and have learnt a lot in this period of time.
>
> With this spirit I would like to work on the idea of "Custom Indexes" 
>   and 
> extend it as my proposal for Google Summer of Code 2016 
> .
>
> I have started preparing my proposal and here is the initial draft 
>  of it. I would like 
> to hear your thoughts regarding this. Also I wanted to discuss some points 
> mentioned below. The timeline still needs work as I am still digging into 
> the code of expressions to see how we can use them in FunctionalIndex. Any 
> pointers/thoughts on that would be appreciated.
>
> Key points:
>   - Introduction to classed based indexes.
>   - Support for custom classes to db_index.
>   - Introduction of Meta.indexes.
>   - Allowing fields to specify their own index type.
>   - Support for a indexes/constraints API. 
>   - Extend expressions into indexes.
>   - Bring spatial indexes under the hood.
>
> Points I would like to discuss:
>  1) Would it be right to *create a IndexTogether class* (subclass of 
> Index) and internally translate Meta.index_together to it ?
>   This would allow something like -
>   class Meta:
>   indexes = [IndexTogether(['field1', 'field2'])]
> I think this would let us keep a better track of any indexes 
> (including those by `index_together`) that are being created. 
> `Meta.index_together` would be internally translated to Meta.indexes. This 
> might also be followed by deprecation of `index_together` if we want.
>
>  2) 
> *Handling Unique constraints via indexes.*  For handling of 
> constraints, I was thinking of creating a UniqueIndex class which would 
> handle any unique constraint on any column and allow other options like to 
> make it deferrable.
>   Right now fields with ``unique=True`` apply the unique constraints 
> by using both the UNIQUE constraint in the CREATE TABLE statement and by 
> creating an index for it. For example, in this model 
> , multiple (repeating) 
> indexes are being generated for the `name` field (one by UNIQUE constraint, 
> 2 others manually, on postgresql). This takes more space and is also not 
> good performancewise. This situation can also be mitigated by keeping a 
> track of all unique constraints at only one place.
>   So I was thinking of bringing the unique constraint totally under 
> indexes. Maybe some `models.UniqueIndex()` could be used in meta.indexes to 
> add constraints ? Any thoughts on it ?
>
>
> I had also prepared a DEP (based on an earlier DEP by Marc Tamlyn), which 
> is now a subset of this proposal.
>
> Regards
> Akshesh Doshi
> (akki)
>

-- 
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/8c3a0f04-4b2a-4c0e-87af-2b9d209681e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FK constraints are not checked at the end of nested atomic blocks

[Gavin Wahl]

I understand that a database is invalid or invalid as a whole, which is why
you don't need to check constraints until transaction commit (when the
transaction becomes visible to the world). Why do you want to bundle
constraint checking with a savepoint release though? They seem logically
unrelated. Wouldn't a standalone way to check deferred constraints be more
useful?

On Wed, Dec 30, 2015 at 4:23 PM, Shai Berger <s...@platonix.com> wrote:

> Hi,
>
> On Tuesday 29 December 2015 19:40:44 Gavin Wahl wrote:
> > What does it even mean for constraints to be checked at savepoint
> commit? I
> > would expect this to not cause any errors:
> >
> > with atomic():
> > # insert invalid fk
> > with atomic(check_deferred_constraints=True):
> > # do stuff that doesn't invalidate any contraints
> > # delete the invalid fk inserted before
> >
>
> I think your expectation is wrong, for both technical and "ideological"
> reasons.
>
> Technically, you can easily do things in the inner block which, although
> they
> do not violate any constraints in themselves, rely on the invalid FK
> record.
> If that were allowed to pass silently, we would violate the expectation
> that
> "if the inner block succeeded, then things in it are ok".
>
> Philosophically, I don't think "checking the constraints only for things I
> changed here" is a valid *logical* operation, as you seem to imply; a
> database
> is valid or broken as a whole. The fact that we can get away with checking
> only the changes at a transaction limit is an *implementation* shortcut,
> valid
> only as far as it is logically equivalent to checking the whole database.
>
> Shai.
>

-- 
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/CACPudh1WTvBi_m%3DJZ%2BZvbWpj-pXu5T%2BpyjEwF%3D5_34pVV-17eA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FK constraints are not checked at the end of nested atomic blocks

[Gavin Wahl]

What does it even mean for constraints to be checked at savepoint commit? I 
would expect this to not cause any errors:

with atomic():
# insert invalid fk
with atomic(check_deferred_constraints=True):
# do stuff that doesn't invalidate any contraints
# delete the invalid fk inserted before

But with the proposed solution _all_ constraints are checked, not just the 
ones invalidated in that savepoint.

-- 
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/a7f4acf5-3a06-4b5f-adb2-ff025f5511a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: makemigrations --exit; exit status feels backwards from conventions

[Gavin Wahl]

In your case, successfully creating a migration indicates a failure. Why do 
you object to using a ! to communicate this?

! ./manage.py makemigrations

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/61887548-63b9-4a45-b1f3-689650e84154%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the admin compatible with CSP

[Gavin Wahl]

>  it was too hard to do a generic one that could be used everywhere

The tag in argonauts works in HTML4, HTML5, and XHTML content, with or 
without CDATA tags. The only place you cant use it is inside an [X]HTML 
attribute.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e2383fcb-08bd-4b59-88fd-55bbd524fc13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the admin compatible with CSP

[Gavin Wahl]

> Having looked around  my solution is to output the json string with {{
json_string|escapejs }}.
> Then in the javascript call JSON.parse twice
> JSON.parse(JSON.parse('"' + jsonString + '"'));

That doesn't seem nice at all. Is there any objection to putting the json
filter from django-argonauts into django?

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh203NvC8SY8wiDi5knpxyeOe9LB6HRn1s0P%3Dd%2BfQYyHkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the admin compatible with CSP

[Gavin Wahl]

I'm very interested in getting this into 1.10. I can devote some time to it 
to help.

When I looked at it before, based on the time I had available, it didn't 
seem feasible for me to remove every single inline script. Especially with 
form widgets that include templated javascript. Instead I was looking at 
the two ways to whitelist scripts with CSP, namely script-nonce and script 
hash sources. The disadvantage with either of these approaches is that they 
need to be integrated with the middleware adding the CSP header, to 
communicate the current page nonce or the list of hashes. script-nonces 
also totally destroy caching, because each response has to have a unique 
nonce that's referenced by each inline script. 

Ideally django admin would just be compatible with whatever CSP header the 
user wants, without any specific integration, so removing all inline 
scripts and styles is certainly preferable if you have the time.

>  Oh, btw please do not handwrite JSON in templates, 

Absolutely, the view should build a data structure representing the data to 
be encoded as JSON rather than templating it.

>  which then only needs to go through the autoescape filter I think

This is actually incorrect. 

Re: Ticket #23242 -- Approximate date_hierarchy

[Gavin Wahl]

Is it going to be possible to get this in before the feature freeze?

On Thursday, September 10, 2015 at 10:21:29 AM UTC-6, Gavin Wahl wrote:
>
> The enum seems fine. Where should it be defined? Should the docs mention 
> the integer values at all, or are you required to use the enum?
>
> I don't think setting date_hierarchy to a tuple is any cleaner.
>
> On Monday, August 31, 2015 at 12:54:21 PM UTC-6, Tim Graham wrote:
>>
>> This seems okay at first glance, though I wonder if an enum-like object 
>> might be better than magic int/boolean values. Something like:
>>
>> class ApproximateWith(object):
>> NONE = 0
>> YEARS = 1
>> MONTHS = 2
>> DAYS = 3
>>
>> Do you think a separate ModelAdmin attribute better than allowing 
>> something like:
>>
>> date_hierarchy = ('pub_date', ApproximateWith.YEARS)
>>
>> Values that can be string or tuple have contributed to bugs in the past, 
>> but I thought it might be worth proposing.
>>
>> On Saturday, August 29, 2015 at 4:50:20 PM UTC-4, Gavin Wahl wrote:
>>>
>>> I'm going to fix ticket #23242 by adding an option to approximate the 
>>> date_hierarchy options instead of calculating them exactly. The 
>>> implementation is straightforward but I'm not sure what the interface 
>>> should be. 
>>>
>>> The basic idea is instead of doing `SELECT DISTINCT date_trunc('year', 
>>> created_at) FROM table`, then a date_trunc('month', created_at) to get the 
>>> list of months, and so on, you can find the range with `SELECT 
>>> date_trunc('year', max(created_at)), date_trunc('year', min(creeated_at))` 
>>> and just assume that every year/month/day in between is filled in.
>>>
>>> How should this feature be enabled? Should it be possible to approximate 
>>> the year list, but once you've selected the year switch to exact? I'm 
>>> thinking something like:
>>>
>>> - approximate_date_hierarchy = False # default
>>> - approximate_date_hierarchy = 1 # approximate years only
>>> - approximate_date_hierarchy = 2 # approximate months and years
>>> - approximate_date_hierarchy = 3 or True # approximate days, months, and 
>>> years
>>>
>>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/86523935-3efa-42ec-ba9e-ed8f50f93f27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket #23242 -- Approximate date_hierarchy

[Gavin Wahl]

The enum seems fine. Where should it be defined? Should the docs mention 
the integer values at all, or are you required to use the enum?

I don't think setting date_hierarchy to a tuple is any cleaner.

On Monday, August 31, 2015 at 12:54:21 PM UTC-6, Tim Graham wrote:
>
> This seems okay at first glance, though I wonder if an enum-like object 
> might be better than magic int/boolean values. Something like:
>
> class ApproximateWith(object):
> NONE = 0
> YEARS = 1
> MONTHS = 2
> DAYS = 3
>
> Do you think a separate ModelAdmin attribute better than allowing 
> something like:
>
> date_hierarchy = ('pub_date', ApproximateWith.YEARS)
>
> Values that can be string or tuple have contributed to bugs in the past, 
> but I thought it might be worth proposing.
>
> On Saturday, August 29, 2015 at 4:50:20 PM UTC-4, Gavin Wahl wrote:
>>
>> I'm going to fix ticket #23242 by adding an option to approximate the 
>> date_hierarchy options instead of calculating them exactly. The 
>> implementation is straightforward but I'm not sure what the interface 
>> should be. 
>>
>> The basic idea is instead of doing `SELECT DISTINCT date_trunc('year', 
>> created_at) FROM table`, then a date_trunc('month', created_at) to get the 
>> list of months, and so on, you can find the range with `SELECT 
>> date_trunc('year', max(created_at)), date_trunc('year', min(creeated_at))` 
>> and just assume that every year/month/day in between is filled in.
>>
>> How should this feature be enabled? Should it be possible to approximate 
>> the year list, but once you've selected the year switch to exact? I'm 
>> thinking something like:
>>
>> - approximate_date_hierarchy = False # default
>> - approximate_date_hierarchy = 1 # approximate years only
>> - approximate_date_hierarchy = 2 # approximate months and years
>> - approximate_date_hierarchy = 3 or True # approximate days, months, and 
>> years
>>
>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/194534a9-c3e5-4b58-ae1f-7f079b70cd24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ticket #23242 -- Approximate date_hierarchy

[Gavin Wahl]

I'm going to fix ticket #23242 by adding an option to approximate the
date_hierarchy options instead of calculating them exactly. The
implementation is straightforward but I'm not sure what the interface
should be.

The basic idea is instead of doing `SELECT DISTINCT date_trunc('year',
created_at) FROM table`, then a date_trunc('month', created_at) to get the
list of months, and so on, you can find the range with `SELECT
date_trunc('year', max(created_at)), date_trunc('year', min(creeated_at))`
and just assume that every year/month/day in between is filled in.

How should this feature be enabled? Should it be possible to approximate
the year list, but once you've selected the year switch to exact? I'm
thinking something like:

- approximate_date_hierarchy = False # default
- approximate_date_hierarchy = 1 # approximate years only
- approximate_date_hierarchy = 2 # approximate months and years
- approximate_date_hierarchy = 3 or True # approximate days, months, and
years

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh1jHA4eUD9Diw74R7_SEiN-KoBPFLWV0J2M7dAGEz43bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CHECK Constraints and migrations

[Gavin Wahl]

> making lookups and transforms work on Python
side, too. Then, when you supply a check  "ends_after_starts", we
could both add it as a database level constraint, and also validate
the constraint on Python side when altering data.

Yep, that's my plan. Just have to figure out the migration stuff first.

On Thu, Aug 27, 2015 at 11:47 PM, Anssi Kääriäinen <akaar...@gmail.com>
wrote:

> I recall another idea that would work very well with model level
> Q-object based checks: making lookups and transforms work on Python
> side, too. Then, when you supply a check  "ends_after_starts", we
> could both add it as a database level constraint, and also validate
> the constraint on Python side when altering data.
>
> I think it is a really good idea to add more control to Fields over
> what migrations they generate, but unfortunately I don't have time nor
> expertise to work on this.
>
>  - Anssi
>
> On Fri, Aug 28, 2015 at 7:30 AM, Andrew Godwin <and...@aeracode.org>
> wrote:
> > No, fields can't really specify any of the SQL used to make/update/delete
> > them (partially as the SQL is heavily dependent on the database backend,
> and
> > Django traditionally has the fields as the database-agnostic bit and the
> > backends as the specific bit). All they can do is supply a db_type, which
> > has to fit in the space a type would go for ADD COLUMN, etc. (that's how
> > contrib.postgres has its fields work, for example).
> >
> > I know that Marc Tamlyn was looking into this for some of his PostgreSQL
> > stuff, and other people have floated some ideas around letting fields
> have
> > more control over migration stuff too - they may be able to chime in
> when we
> > get to a sensible time in Europe on this.
> >
> > I'm definitely far from the only person who can work on fixing up the
> > migration stuff; in fact, I haven't done much to it at all recently and
> it's
> > been all other people, so if you think you want to take a stab at it,
> you're
> > more than welcome, and I'm more than happy to review patches against
> > migrations.
> >
> > Andrew
> >
> > On Thu, Aug 27, 2015 at 9:25 PM, Gavin Wahl <gavinw...@gmail.com> wrote:
> >>
> >> That's too bad. I don't think it's really worth it unless the experience
> >> works seamlessly, because if I'm going to write a migration manually I
> might
> >> as well just use a RunSQL. I did have another slightly hacky idea that
> might
> >> work. Can custom Fields specify the operations used to create and drop
> them?
> >> It might then be possible to write a pseudo-field called 'Check':
> >>
> >> class FooModel(models.Model):
> >> # ...
> >> check_ends_after_start = Check(Q(end_date__isnull=True) |
> >> Q(end_date__gt=F('start_date')))
> >>
> >> That instead of adding a column called ends_after_start, it would add a
> >> constraint.
> >>
> >> Do you think it's possible for anyone besides you to work on making the
> >> migration framework more extensible? I'm interested in contributing in
> this
> >> area.
> >>
> >>
> >> On Thursday, August 27, 2015 at 8:07:55 PM UTC-6, Andrew Godwin wrote:
> >>>
> >>> Hi Gavin,
> >>>
> >>> Hooking into the migration autodetector is currently not really
> possible
> >>> - it's quite inextensible, which is something I'd love to get ironed
> out in
> >>> the long term but isn't really possible right now to modify it from
> >>> third-party code.
> >>>
> >>> You can, however, supply custom migration Operation classes that people
> >>> could put into their migrations manually, or potentially have some
> other way
> >>> of outputting those migration files with operations in them (a lot of
> the
> >>> code to write them out is re-useable). Hopefully someone else has a
> better
> >>> idea!
> >>>
> >>> Andrew
> >>>
> >>> On Thu, Aug 27, 2015 at 6:27 PM, Gavin Wahl <gavi...@gmail.com> wrote:
> >>>>
> >>>> I'm interested in writing a third-party app that allows users to
> >>>> declaratively write check constraints and have them automatically be
> added
> >>>> and removed by migrations. I'm envisioning being able to attach a
> list of Q
> >>>> objects to your model, something like:
> >>>>
> >>>>
> >>>> class Meta:
> >>>> checks = [
> >>>> 

CHECK Constraints and migrations

[Gavin Wahl]

I'm interested in writing a third-party app that allows users to
declaratively write check constraints and have them automatically be added
and removed by migrations. I'm envisioning being able to attach a list of Q
objects to your model, something like:


class Meta:
checks = [
Q(end_date__isnull=True) | Q(end_date__gt=F('start_date'))
]

Now that we have migrations, formalized Meta, and custom lookups, is it
possible for a third-party app to manage this seamlessly?

I'm having trouble figuring out where it could hook in to migrations to
detect changes to the check constraints, and automatically generate the
migrations with operations to update the constraints. What code I should be
reading to figure out how to do it?

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh1gRB_Jov_bH-maDGr4EBRugFuV3Y%2BBzYM9w0yyki7zkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

[Gavin Wahl]

> How so? You cannot just ajax-fetch stuff from different domains.

I'm talking about a single domain. Injected javascript on a page that
doesn't contain the CSRF token can fetch a different page on the same
domain to get it.

> If you already injected javascript onto the victims page (XSS) there is no 
> need to fetch the CSRF token, you already got greater control.

Well, the HttpOnly flag is intended to reduce the damage an attacker
can do once the already can inject javascript. But I agree -- hiding
the CSRF token from javascript doesn't increase security in any way,
but the documentation implies it does. I want to make it clear in the
documentation that this setting has no meaningful effect.

> If you still think you have a valid attack vector there, please send it to 
> secur...@djangoproject.com and add a bit more explanation.

There is no attack vector. This is just about misleading documentation.

On Mon, May 4, 2015 at 5:58 AM, Florian Apolloner <f.apollo...@gmail.com> wrote:
> On Monday, April 20, 2015 at 6:38:55 AM UTC+2, Gavin Wahl wrote:
>>>
>>> > Though it could still ajax-in the token from a page that does have it,
>>> > right?
>>
>>
>> Exactly right.
>
>
> How so? You cannot just ajax-fetch stuff from different domains. The usual
> security policies will forbid that. If you already injected javascript onto
> the victims page (XSS) there is no need to fetch the CSRF token, you already
> got greater control. If you still think you have a valid attack vector
> there, please send it to secur...@djangoproject.com and add a bit more
> explanation.
>
> Thanks & cheers,
> Florian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/nXjfLd8ba5k/unsubscribe.
> To unsubscribe from this group and all its topics, 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/7609a5bf-65d9-468a-8f64-c5e906cf5920%40googlegroups.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh2WQSZdxwvZt-D_FyCvAU-N0ajmTXxJcBXDYmTuZixWrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

[Gavin Wahl]

>
> > Though it could still ajax-in the token from a page that does have it, 
> right?
>

Exactly right.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/16eca983-b270-49cc-9a82-5801f42b3d1f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CSRF_COOKIE_HTTPONLY is misleading and not useful

[Gavin Wahl]

Ticket #15808 added the CSRF_COOKIE_HTTPONLY setting to set the
HttpOnly attribute on the csrftoken cookie. The HttpOnly attribute is
intended to prevent accessing a cookie through the DOM interface, only
sending it over HTTP. This improves security for session cookies
because it prevents XSS attacks from accessing the session id.

The CSRF token is used through the DOM though, by embedding it in the
HTML of a form, so it's always accesible through JavaScript anyway.
The docs even suggest how to negate the effect of the setting:

> This can help prevent malicious JavaScript from bypassing CSRF protection. If 
> you enable this and need to send the value of the CSRF token with Ajax 
> requests, your JavaScript will need to pull the value from a hidden CSRF 
> token form input on the page instead of from the cookie.

The first sentence isn't actually true. HttpOnly can't prevent
JavaScript from obtaining the csrftoken, because the csrftoken has to
be in the DOM anyway. The second sentence suggests doing something
that completely negates the effect of the setting, so why use it at
all?

I understand that this setting may exist only to satisfy misguided
security scanners and not to actually improve security. If that's the
case, the implication that this setting improves security should be
removed from the docs.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh1Nn-Cz5hJivvTVcfD%3DSSB2E9ZC2s-2mnje88kARKjBfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Testing email settings

[Gavin Wahl]

> Thus, the test sending email is quite unnecessary, I would like a check
that connects to the SMTP server (if the emails settings are
setup else do nothing) when the application starts.

This wouldn't be useful to me at all. For one, it only is defined for an 
SMTP backend. Also, I wouldn't trust that a successful connection means 
that the configuration is correct. I've seen circumstances, especially if 
sending through a local sendmail, that will result in a successful 
connection but there is still a misconfiguration. 

I expect this command to work with any email backend and to actually do a 
complete, end-to-end test of the configuration.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6645495f-dbd3-42b9-afc4-5c5a204af487%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: enum fields in django

[Gavin Wahl]

I would definitely use an enum field that used pep 435 enums instead of 
choices. The implementation as a real enum in postgres and choices on other 
databases is perfect. I've used a third-party 
package, https://github.com/hzdg/django-enumfields, to accomplish this in 
the past. The ability to use real python enums is a great improvement over 
defining constants for each choice yourself.

On Wednesday, February 25, 2015 at 7:53:34 PM UTC-7, Thomas Stephenson 
wrote:
>
> As discussed in Issue 24342 , 
> I've got an implementation of EnumField that we've found useful when 
> developing our django REST API that I'd like to add to django core. It was 
> suggested I bring this issue up in the developers mailing list for 
> discussion. Unfortunately, updates to the issue were delivered to my spam 
> folder, so there has been some delay in actually raising the issue.
>
> Basically, the implementation consists of a new field type, and a new 
> migration operation (to register the values associated with an enum type). 
> The field takes an `enum_type` argument and registers a type with values 
> taken from the enum value names. The actual values associated with the 
> names are ignored, so support for IntEnum and other enum types comes as 
> standard.
>
> In a real implementation, the enum type would have to be checked when 
> running migrations to ensure that values haven't been added/removed from 
> the python class. It's not something that we've needed to deal with in our 
> in-house implementation.
>
> Any database which does not support an enum field natively would default 
> to a CharField implementation. 
>
> Useful addition? Or does it overlap too much with the choices API? 
>
> Thomas
>
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba1294df-7fea-4f46-b5ff-3d6ad3909cda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Testing email settings

[Gavin Wahl]

I opened a ticket for this but was asked to discuss it on the mailing list.

When configuring django to send emails through an SMTP server, there are 
usually many different settings to try to get it to work. I've written a 
management command that just sends an email to make testing the settings 
easier. I'm wonder if there's any interest in including this command in 
django?
Here's the command: 
​https://github.com/fusionbox/django-fusionbox/blob/master/fusionbox/core/management/commands/send_test_email.py

https://code.djangoproject.com/ticket/24419

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/910e45cf-39f1-421b-bae4-667a21069388%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modify get_or_create() to use field lookups parameters for values

[Gavin Wahl]

That is how it works now.


On Sat, Jul 26, 2014 at 6:38 AM, Mattias Linnap  wrote:

> One way to make it work in presence of field lookups would be to demand
> that the full values of mandatory fields must be present in the defaults
> dictionary.
>
> For example:
> Model.objects.get_or_create(name_iexact='hello', defaults={'name':
> 'Hello', 'slug': 'foo'}) or
> Model.objects.get_or_create(pub_date__month=12, defaults={'pub_date':
> timezone.now().date()})
>
>
> On Tuesday, 10 June 2014 08:26:07 UTC+3, gavi...@gmail.com wrote:
>>
>> I don't think this is possible to do generally. What would count__gt=1 or
>> pub_date__month=12 do?
>>
>> On Friday, June 6, 2014 3:50:08 PM UTC-6, Patrick Bregman wrote:
>>>
>>> Hi all,
>>>
>>> First of, I'm new to this list so please tell me if there's something
>>> that can be done better. It's the best way to learn for me ;)
>>>
>>> Recently I've been doing some reworking of an old (think Django 1.1 or
>>> 1.2) webapp of mine into the latest and greatest of Django. In the process
>>> I modified some models, and thought that *get_or_create* would be
>>> perfect to replace boring try / except cases. Except that it didn't really
>>> work as planned. I tried to do a *get_or_create(name__iexact=value,
>>> defaults={'slug': slugify(value)})*. I expected this to be smart enough
>>> to know that it should fill the field *name* based on the *name__iexact*
>>> parameter. Apparently it isn't :) In this case you'd need to add a
>>> definition for *name* to the *defaults* dict to get the value into the
>>> newly created model. I'm not sure, but I personally think this shouldn't be
>>> that hard to fix. It's basically checking (and removing) known field
>>> lookups or simply everything after a double underscore, and using that as a
>>> field name. Or at least, that's my view on it.
>>>
>>> The big question is:
>>> 1. Is this behavior that exotic that I'm the first one to notice, or did
>>> I do a wrong search on Google?
>>> 2. Would this indeed be as easy (or comparably easy) as I think?
>>> 3. Is this behavior we actually want in Django?
>>>
>>> If the answer to 2 and 3 are yes, I'll look into giving it a try to
>>> making a patch for this myself.
>>>
>>> Regards,
>>> Patrick Bregman
>>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/EbLRpYB_1WI/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/dbe4723f-2a8c-4a5c-94cd-be264c1198ef%40googlegroups.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://groups.google.com/d/msgid/django-developers/CACPudh2XpFvA%3Dx9S5G1HUbr3wu3pCQpLdYfaFX8dn00cYYcsQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: modelformset_factory and unique_together don't always validate unique fields

[Gavin Wahl]

The problem is when a subset of the fields in a unique_together constraint
are in the form.


On Thu, Jul 3, 2014 at 11:48 AM, Florian Apolloner 
wrote:

>
>
> On Thursday, July 3, 2014 3:03:25 PM UTC+2, Jon Dufresne wrote:
>>
>> > Also, even if we find a place to show
>> > the errors, the user is (usually) in no position to correct them (after
>> all,
>> > there is no field he could change to fix it).
>>
>> I don't follow. In my specific example the user is able to change the
>> "name" field. In my opinion, the form should fail to validate because
>> the _user_ entered "newname" twice, for two different names when they
>> should be unique. The user is in the position to 1) make these
>> conflict and 2) correct them.
>>
>
> I don't follow; if the user is able to change the "name" field; it's
> included in the form and uniqueness is checked, I thought we are talking
> about fields __not__ included in a form.
>
> Cheers,
> florian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/FmllO4t53bE/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/53cd7280-38ba-40cb-aff1-0f9558673b39%40googlegroups.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://groups.google.com/d/msgid/django-developers/CACPudh3zYndf9HG6R7dEDs9YK_6UjQ0K2TUMHnaNPAwqbfmhcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request: New middleware method for "universal" decoration

[Gavin Wahl]

I really like the idea of implementing this as a url pattern decorator.
This seems similar to Alex Gaynor's talk about everything being a view.
It's more flexible than a middleware because you can decorate any part of
the urls tree, such as the patterns for a single reusable app.

urls = decorate_recursively(login_required, patterns(...))

This is actually possible to implement today, see snippets like
https://djangosnippets.org/snippets/2532/. The code required is kind of
ugly, so I think it would benefit from an implementation in core.


On Thu, Oct 17, 2013 at 12:19 AM, Anssi Kääriäinen
wrote:

> On Wednesday, October 16, 2013 8:36:05 PM UTC+3, Shai Berger wrote:
>
>> I think the middlewares have grown a little complicated, and I'd try to
>> avoid
>> adding functionality there. That said, the feature of universal
>> decoration
>> seems like it is worthwhile. I'd try to see if it can be added through
>> the
>> urls mechanism instead -- you'd get behavior that is more like a
>> decorator, in
>> the sense that decoration would happen only once.
>>
>
> I hacked together a branch where middlewares could define wrap_request and
> wrap_view methods in addition to all existing process_* methods. The
> wrap_request and wrap_view methods are call-through. It turns out that it
> will be impossible to both bubble up exceptions through wrap_* methods
> while also supporting current middleware semantics. Currently exceptions
> get converted immediately to 500 responses. Doing that and also raising the
> exception through the stack is obviously impossible.
>
> Allowing view wrapping in urls.py seems like a good solution. It would
> allow for what ATOMIC_REQUESTS does currently. And more - it would allow
> wrapping just part of your views, not all of them. Having the ability to
> apply permission_required to a collection of views from urls.py seems like
> a nice feature.
>
> That still leaves whole request wrapping into impossible to achieve state.
> Maybe guarantee that all process_response methods are ran even if some of
> the raise exceptions is enough?
>
> Currently there is no guarantee that all process_response methods get
> called. It seems that support for that would be fairly small backwards
> incompatible change. See:
> https://github.com/akaariai/django/commit/cc459994bb7899e744471dcb7ec034e6e1c310af.
> This would add a guarantee that if process_request is called, then matching
> process_response gets called, too. Notable there is still no guarantee that
> if process_response is called, then process_request was also called. But
> changing that isn't easy to do.
>
>  - Anssi
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/4TnXsONNEso/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/98bd7629-38f1-409e-b2c1-1a058ed3559e%40googlegroups.com
> .
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh1xghzzyOHKcgz8fawFzWEJunLu6AAbJfBYgCdH1tBkHg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Username Independence in Auth Forms

[Gavin Wahl]

> The current code assumes that if you write a custom model, you'll also
write the corresponding custom forms.

Right. This is what I am proposing be fixed.


On Mon, Jun 3, 2013 at 12:31 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 3 juin 2013, at 20:01, gavinw...@gmail.com wrote:
>
> > Some of the built-in auth forms only work on user models whose
> `USERNAME_FIELD` is `username`.
>
> Hi Gavin,
>
> The current code assumes that if you write a custom model, you'll also
> write the corresponding custom forms.
>
> You may want to have a look at 
> https://code.djangoproject.com/ticket/19353which describes the same problem 
> (as far as I can tell).
>
> --
> Aymeric.
>
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/XxaZ50SxPj4/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, 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.

Help with #20378 - Reverse join fails when GenericRelation is defined on an abstract model

[Gavin Wahl]

I'd like to have a go at fixing this bug, but I'm not sure where to start. 
The problem seems to be that there's only a single instance of the field 
per model, so field.model is always the abstract class. I can't see a way 
to access the concrete class from the field instance. If the field only has 
a reference to the abstract model, which doesn't have a pk, how can it 
calculate join columns for the concrete model?

https://code.djangoproject.com/ticket/20378

-- 
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: Is casting Field.help_text to string in Field.__init__ necessary?

[Gavin Wahl]

+1. This has been a problem for me too.

On Saturday, March 23, 2013 5:16:15 AM UTC-6, Evgeny wrote:
>
> Hi.
>
> Is it necessary to cast help_text to string in Field.__init__ there 
> https://github.com/django/django/blob/master/django/forms/fields.py#L92 ? 
> I will be eventually displayed as string in template, and will be casted 
> there. I think it would be better design - cast string type only in last 
> moment in presentation template.
>  
> I am asking because i try to display in template two help texts one to the 
> right from the field and one to the bottom, and to do that i tried to pass 
> in help_text tuple of two strings but failed because of that cast.
>
> Thanks.
>

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

#19076 - TemplateView does not support setting mime type

[Gavin Wahl]

I know this is last minute, but is there any chance of getting this change 
in 1.5? It's a simple change, and is necessary now that direct_to_template 
is gone.

https://code.djangoproject.com/ticket/19076

-- 
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/-/1ksTGUqQ2Z0J.
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: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

[Gavin Wahl]

>> - A hypothetical middleware that appends debug information to the end
>>   of the response. debug-toolbar may be able to work like this.
> Looking for the  boils down to the same problem as above, and can't be 
> implemented without consuming the content for the same reason.

It can be done, it's just a little harder for streaming. If the chunk
you are processing ends with any prefix of '', that is, ('<',
'' again.. I don't think this counts as 'consuming' the
content, because you'll only combine combine a few chunks, and only
when necessary.

This treatment, while difficult, is totally necessary when dealing
with iterators over responses, no matter the API. Since you have to
write the complex stream processing anyway (assuming you want to work
with streaming responses), HttpResponse should not force you to write
an additional implementation for the plain, non-streaming response.

> You can probably abstract the pattern in a response middleware base class.
That's a good idea, and it's probably what I'll do if this doesn't
make it into Django. I think this use case is common enough for
HttpResponse to handle, though.

-- 
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: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

[Gavin Wahl]

 - GzipMiddleware (compress_string(x) == compress_sequence([x]))
 - StripWhitespaceMiddleware
 - ContentDoctorMiddleware (https://github.com/unomena/django-content-doctor)
 - A hypothetical middleware that appends debug information to the end
of the response. debug-toolbar may be able to work like this.

On Wed, Nov 28, 2012 at 11:07 AM, Aymeric Augustin
<aymeric.augus...@polytechnique.org> wrote:
> 2012/11/28 Gavin Wahl <gavinw...@gmail.com>
>>
>> I would like to avoid having two code paths, one with streaming and one
>> without, in new middleware.
>
>
> Hi Gavin,
>
> Could you give an example of a middleware that:
>   - needs to alter the content,
>   - will work identically both on regular HttpResponses and
> StreamingHttpResponses,
>   - will not consume a streamed content (that's part of the contract of
> StreamingHttpResponse)?
>
> Thanks,
>
> --
> 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.

-- 
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: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)

[Gavin Wahl]

I would like to avoid having two code paths, one with streaming and one
without, in new middleware. 

If `HttpResponse` followed the the `streaming_content` API as well, when
writing a streaming-aware middleware instead of writing

if response.streaming:
response.streaming_content = 
wrap_streaming_content(response.streaming_content)
else:
response.content = wrap_content(response.content)

One could write
  
  response.streaming_content = 
wrap_streaming_content(response.streaming_content)

The behavior for `StreamingHttpResponse` would be the same, but 
`HttpResponse`
would consume the iterator assigned to `streaming_content` and store it in
`content`. Since an iterator (`streaming_content`) can be trivially 
converted
to a string (`content`), this would prevent having to write to versions of
`wrap_content`, one for iterators and the other for strings.

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