Re: [Django] #26625: Check that related_name doesn't contain double underscores

[Django]

#26625: Check that related_name doesn't contain double underscores
-+-
 Reporter:  charettes|Owner:  filias
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by filias):

 * owner:  nobody => filias
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f20c75c5b8de92af33fa2a51f6764d5d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26626: Update decorator_from_middleware to work with new-style middleware

[Django]

#26626: Update decorator_from_middleware to work with new-style middleware
---+
 Reporter:  timgraham  |Owner:  carljm
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

 * status:  new => assigned
 * owner:  nobody => carljm


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ec7a85516fcacc742706ae52efa769f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26627: outermost atomic block executes on_commit callbacks registered in another outermost atomic block

[Django]

#26627: outermost atomic block executes on_commit callbacks registered in 
another
outermost atomic block
-+-
 Reporter:  bartdag  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.73a44d8e0ed27f12130df0962caba258%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sqlite nose| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by yakky):

 My experience with this issue is mostly related to ManyToMany fields.
 I even traced all the SQL queries, and apparently sqlite does not handle
 the cleanup phase well and segfaults when truncating the data when
 destroying database. I can try reproduce this and post the log, if this
 can be useful.
 I managed to solve that by clearing many to many fields in `tearDown`:

 {{{#!python
 def tearDown(self):
 self.user.sites.clear()
 for post in Post.objects.all():
 post.sites.clear()
 post.tags.clear()
 super(BaseTest, self).tearDown()
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.c5e9d60b301c685081f04d45e7690dff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26631: Tutorial Part 6: Lacking import static for static files

[Django]

#26631: Tutorial Part 6: Lacking import static for static files
---+--
 Reporter:  donkeyDau  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.9
 Severity:  Normal |   Keywords:  tutorial
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 In the tutorial in step 6
 (https://docs.djangoproject.com/en/1.9/intro/tutorial06/) the following
 code is used:
 {{{
 {% load staticfiles %}

 
 }}}
 It wouldn't work when I tried. I figured out that I have to import

 {{{
 from django.conf.urls.static import static
 }}}
 to get it work properly.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.838beaf5f0833262a10f7be3c351473c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26630: Defered constraint checks flush after `post_delete` signal

[Django]

#26630: Defered constraint checks flush after `post_delete` signal
-+-
 Reporter:  alexmadjar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by alexmadjar):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Only tried on CASCADE deletes, I think it blames to this code -
 https://github.com/django/django/blob/master/django/db/models/deletion.py#L15

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.4c2010fd95c0a6ebfd2cc0e1ab3812dc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26630: Defered constraint checks flush after `post_delete` signal

[Django]

#26630: Defered constraint checks flush after `post_delete` signal
--+
 Reporter:  alexmadjar|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Repro steps:

 1.  Use a database that supports `can_defer_constraint_checks` (tested on
 postgres)
 1.  Have a model (A) with a `null=True` ForeignKey or OneToOneField (F) to
 another model (B)
 1.  Connect a function to listen to `post_delete` on (B) that pulls
 objects of type (A) from the db (using a = A.objects.get... etc )
 1.  Try to access a.F for an object a that used to be associated with the
 deleted instance of B that was just deleted

 Expectation:  a.F_id is `None`

 Actually:  a.F_id is the id of the deleted instance and a.F raises an
 ObjectDoesNotExist exception

 Note: doesn't repro on fields where `null=False` or on sqlite.  My
 diagnosis is that A's field isn't being properly cleared (or A objects
 deleted in the case of on delete CASCADE) because the constraint checks
 aren't being flushed until _after_ the `post_delete` signal fires

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.f3c1869f725560891e1948d52aed5d67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26615: Changing user's email could invalidate password reset tokens

[Django]

#26615: Changing user's email could invalidate password reset tokens
--+
 Reporter:  Alex  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by SilasX):

 [https://github.com/django/django/pull/6621 PR resubmit 2]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.7a46d56a45bea158aa0cb1188f0215e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26615: Changing user's email could invalidate password reset tokens

[Django]

#26615: Changing user's email could invalidate password reset tokens
--+
 Reporter:  Alex  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by SilasX):

 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/6620 PR resubmit]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.6d58c8075436faa9ab26078b12702f4d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26613: SQLite3 DB backend should remove dependency on sqlite3 module

[Django]

#26613: SQLite3 DB backend should remove dependency on sqlite3 module
-+-
 Reporter:  Gatzy118 |Owner:  pnl8zp
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"3630b49b556785af63077407418296ada31b0b3e" 3630b49]:
 {{{
 #!CommitTicketReference repository=""
 revision="3630b49b556785af63077407418296ada31b0b3e"
 Fixed #26613 -- Made sqlite3 optional in SchemaEditor.quote_value().
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.12adecf6d27a357834be5ffc253c61b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26613: SQLite3 DB backend should remove dependency on sqlite3 module

[Django]

#26613: SQLite3 DB backend should remove dependency on sqlite3 module
-+-
 Reporter:  Gatzy118 |Owner:  pnl8zp
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.139caff12431bc9c44b2bb65b70b33a2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14415: Multiple aliases for one database: testing problems

[Django]

#14415: Multiple aliases for one database: testing problems
-+-
 Reporter:  shai |Owner:  boaz85
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  multidb, multiple| Triage Stage:  Accepted
  databases, multiple aliases|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"5f23f904af387225b685c633014bddbec1cdd256" 5f23f90]:
 {{{
 #!CommitTicketReference repository=""
 revision="5f23f904af387225b685c633014bddbec1cdd256"
 Fixed #14415 -- Used the test database name in
 BaseDatabaseCreation.test_db_signature().
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.00a9560a0f77ebe1951b6e945e2f83d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26622: Improve timezone documentation regarding requirement for pytz

[Django]

#26622: Improve timezone documentation regarding requirement for pytz
--+
 Reporter:  jarshwah  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * stage:  Unreviewed => Accepted


Comment:

 [https://groups.google.com/d/topic/django-
 developers/OAV3FChfuPM/discussion django-developers discussion]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0a40ae6202616307f10acd85a1ec7880%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26620: refresh_from_db() shouldn't ignore unknown keyword argumengs

[Django]

#26620: refresh_from_db() shouldn't ignore unknown keyword argumengs
-+-
 Reporter:  intgr|Owner:  intgr
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * cc: akaariai (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 Anssi, did you have a reason for the original design?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.cddb8d60c81d75744cd5096e0c3bf462%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24080: Sqlite segmentation fault regression when running tests (since 1.7.2)

[Django]

#24080: Sqlite segmentation fault regression when running tests (since 1.7.2)
---+
 Reporter:  stevejalim |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  sqlite nose| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by stebunovd):

 Colleague of mine discovered a workaround - try renaming test methods to
 change their execution order. For example, rename the method on which
 Segmentation fault occurs to be the first in its test class (in
 alphabetical order). Sounds weird, but it worked both for him and for me.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.7e76fab398f5e165dfac43f6f990648f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26628: CSRF violations should be logged

[Django]

#26628: CSRF violations should be logged
---+--
 Reporter:  jacobian   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  CSRF   |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  csrf security  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by timgraham):

 The `CsrfViewMiddleware` does have
 
[https://github.com/django/django/blob/f179113e6cbc8ba0a8d4e87e1d4410fb61d63e75/django/middleware/csrf.py#L100-L108
 logging for rejected requests]. Is this insufficient? I couldn't find this
 mentioned in the documentation so that could be added, at least.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.24d4b144eaeb843e42f564cd9f0fcfd5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24067: Renaming models prompts for content type deletions

[Django]

#24067: Renaming models prompts for content type deletions
-+-
 Reporter:  doepunk  |Owner:  charettes
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"f179113e6cbc8ba0a8d4e87e1d4410fb61d63e75" f179113e]:
 {{{
 #!CommitTicketReference repository=""
 revision="f179113e6cbc8ba0a8d4e87e1d4410fb61d63e75"
 Fixed #24067 -- Renamed content types upon model renaming.

 Thanks to Tim for the extensive review.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.9caa6789f9383ccebfc2e15ffa519a6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26629: Login failures should be logged

[Django]

#26629: Login failures should be logged
-+-
 Reporter:  jacobian |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  login security   | Triage Stage:
  logigng|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #20495. Feel free to continue the discussion there and reopen
 if you feel my closing was in error.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bf2aaf6b79900faf4e0a77006f9abf89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26629: Login failures should be logged

[Django]

#26629: Login failures should be logged
-+-
   Reporter:  jacobian   |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  1.9
  contrib.auth   |   Keywords:  login security
   Severity:  Normal |  logigng
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Login failures [*] should emit logging messages. There are a couple of
 good reasons for this:

 - Many compliance regimes (all those deriving from NIST-800-53, so FISMA,
 PCI, HIPAA, etc) require logging of failed login attempts.
 - It'll makes integration with a SIEM easier out of the box.

 [*] we may want to log successes, too, or have a configuration option or
 somesuch. I tend to think successes are noise, but reasonable people
 disagree on that point.

 [One of a series of bugs from a discussion I had with @mallyvai about
 improving the security of Django's admin - see
 https://gist.github.com/mallyvai/bcb0bb827d6d53212879dff23cf15d03 for the
 full list.]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.0301dc2d3511d313652e35c6727dc0e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26628: CSRF violations should be logged

[Django]

#26628: CSRF violations should be logged
---+---
   Reporter:  jacobian |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  CSRF |Version:  1.9
   Severity:  Normal   |   Keywords:  csrf security
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
 It's currently possible to log CSRF exceptions with the 403 handler. But a
 more sensible default would be to log them by default. This would be an
 easy simple step that would make Django play more nicely with a SIEM

 [One of a series of bugs from a discussion I had with @mallyvai about
 improving the security of Django's admin - see
 https://gist.github.com/mallyvai/bcb0bb827d6d53212879dff23cf15d03 for the
 full list.]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.86a22b9857a465766f676ea19e22af08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26627: outermost atomic block executes on_commit callbacks registered in another outermost atomic block

[Django]

#26627: outermost atomic block executes on_commit callbacks registered in 
another
outermost atomic block
-+-
 Reporter:  bartdag  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0dde6918d089a978b296193162e4c0f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26627: outermost atomic block executes on_commit callbacks registered in another outermost atomic block

[Django]

#26627: outermost atomic block executes on_commit callbacks registered in 
another
outermost atomic block
-+-
 Reporter:  bartdag  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bartdag):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I submitted a pull request based on Carl Meyer's suggestion:
 https://github.com/django/django/pull/6617

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.12d75b722a82de2d45d29d4df02239af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26627: outermost atomic block executes on_commit callbacks registered in another outermost atomic block

[Django]

#26627: outermost atomic block executes on_commit callbacks registered in 
another
outermost atomic block
--+
 Reporter:  bartdag   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The on_commit hook executes callbacks in an undesired order because the
 list of callbacks is tied to the connection instead of being tied to the
 transaction or atomic block. Consider the following code:

 {{{
 from django.db import transaction
 from foobar.models import Model1, Model2

 @transaction.atomic
 def outer():
 print("START - OUTER")
 for i in range(4):
 f1(i)
 print("END - OUTER")

 @transaction.atomic
 def f1(i):
 model = Model1(description="test {0}".format(i))
 model.save()
 transaction.on_commit(lambda: commit_hook(model, i))

 def commit_hook(model, i):
 print("START - on_commit hook")
 f2(i)
 print("STOP - on_commit hook")

 @transaction.atomic
 def f2(i):
 print("CALLING F2")
 model = Model2(description="test {0}".format(i))
 model.save()
 }}}

 The expected trace when calling outer() is:
 {{{
 START - OUTER
 END - OUTER
 START - on_commit hook
 CALLING F2
 STOP - on_commit hook
 START - on_commit hook
 CALLING F2
 STOP - on_commit hook
 START - on_commit hook
 CALLING F2
 STOP - on_commit hook
 START - on_commit hook
 CALLING F2
 STOP - on_commit hook
 }}}

 But the actual trace is:
 {{{
 START - OUTER
 END - OUTER
 START - on_commit hook
 CALLING F2
 START - on_commit hook
 CALLING F2
 START - on_commit hook
 CALLING F2
 START - on_commit hook
 CALLING F2
 STOP - on_commit hook
 STOP - on_commit hook
 STOP - on_commit hook
 STOP - on_commit hook
 }}}

 Essentially, the outermost atomic block on f2() is executing the callbacks
 registered by the outermost atomic block on outer(), which creates a stack
 of calls instead of a sequence of calls.

 This has been discussed on the [https://groups.google.com/forum/#!topic
 /django-users/e2lbYGqKszo Django user list] and more examples of why this
 can lead to undesired behaviors are given there.

 Carl Meyer has suggested a fix. I'll provide a regression test and a fix
 today.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.0df4d2ab0ea75a8e645d2daa22be8986%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26626: Update decorator_from_middleware to work with new-style middleware

[Django]

#26626: Update decorator_from_middleware to work with new-style middleware
-+
   Reporter:  timgraham  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  HTTP handling  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 @carljm is working on it: "I did work on updating
 `decorator_from_middleware` yesterday and have an in-progress patch. I
 don't think we should plan on the patch for alpha (it's nontrivial and
 will need review), but if it's ok to do it as a follow-up cleanup fix for
 beta, then yeah I think it's be good to have it for 1.10.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.82a84cd6196e5042353425d5cb7da3e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24067: Renaming models prompts for content type deletions

[Django]

#24067: Renaming models prompts for content type deletions
-+-
 Reporter:  doepunk  |Owner:  charettes
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2d1d8f8276a19068ebf98001bc6cace2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26601: DEP5 implementation: Improved middleware

[Django]

#26601: DEP5 implementation: Improved middleware
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In 05c888ffb843ba3eff06cd07b3cef5bbb513a54f:

 Refs #26601 -- Refactored BaseHandler to prepare for new-style middleware.

 In 9baf692a58de78dba13aa582098781675367c329:

 Fixed #26601 -- Improved middleware per DEP 0005.

 In ece4d24f8e494129c098868fa792400937941fab:

 Refs #26601 -- Deprecated old-style middleware.

 In 354acd04af524ad82002b903df1189581c51cabe:

 Refs #26601 -- Added a warning if both MIDDLEWARE AND MIDDLEWARE_CLASSES
 are set.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8c17d6e6502c0a6f2e45c4a1958b1161%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26625: Check that related_name doesn't contain double underscores

[Django]

#26625: Check that related_name doesn't contain double underscores
-+-
   Reporter:  charettes  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 This can lead to strange failures as
 [https://groups.google.com/forum/#!topic/django-users/vR6eR1l3AaY reported
 in @django-users].

 The
 `django.db.models.fields.related.RelatedField._check_related_name_is_valid`
 method is where the changes should be done.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.084d96ebbe19d29e384ba2ec8f9d91b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25774: Refactor of datetime expressions and better, official support for right-hand-side date part extraction

[Django]

#25774: Refactor of datetime expressions and better, official support for right-
hand-side date part extraction
-+-
 Reporter:  ryuusenshi   |Owner:  jarshwah
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  db,expressions,date,time,extract,transform|  checkin
  1.10   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.7137aeb6a7154d8d58a0215c31fd7f05%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26624: Error when running sqlmigrate after dropping index (of index_together) without actually migrating

[Django]

#26624: Error when running sqlmigrate after dropping index (of index_together)
without actually migrating
--+--
 Reporter:  akki  |Owner:  
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  sqlmigrate index  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by akki):

 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Old description:

> I get an error when I run `sqlmigrate` for a migration which drops an
> `index_together` constraint until actually migrating the previous
> migration.
>
> Steps to reproduce the bug:
>
> 1) Create app with the following models:
> {{{
> #!python
> from django.db import models
>
> class Brand(models.Model):
> name = models.CharField(max_length=100, db_index=True)
> value = models.IntegerField(blank=True, null=True, default=0)
>
> class Meta:
> index_together = (
> ('name', 'value'),
> )
> }}}
>
> Run `python manage.py makemigrations`.
> Then see the sql statements using `python manage.py sqlmigrate 
> 0001_initial`.
> Everything works fine.
>
> 2) Remove the `index_together` part (and the whole `Meta` class).
>
> Now run `python manage.py makemigrations`.
> Then see the sql statements using `python manage.py sqlmigrate 
> ` and an error is thrown.
>
> {{{
>
> Traceback (most recent call last):
>   File "manage.py", line 22, in 
> execute_from_command_line(sys.argv)
>   File "d:\git\django\django\core\management\__init__.py", line 367, in
> execute_from_command_line
> utility.execute()
>   File "d:\git\django\django\core\management\__init__.py", line 359, in
> execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "d:\git\django\django\core\management\base.py", line 305, in
> run_from_argv
> self.execute(*args, **cmd_options)
>   File "d:\git\django\django\core\management\commands\sqlmigrate.py",
> line 33, in execute
> return super(Command, self).execute(*args, **options)
>   File "d:\git\django\django\core\management\base.py", line 356, in
> execute
> output = self.handle(*args, **options)
>   File "d:\git\django\django\core\management\commands\sqlmigrate.py",
> line 62, in handle
> sql_statements = executor.collect_sql(plan)
>   File "d:\git\django\django\db\migrations\executor.py", line 177, in
> collect_sql
> state = migration.apply(state, schema_editor, collect_sql=True)
>   File "d:\git\django\django\db\migrations\migration.py", line 129, in
> apply
> operation.database_forwards(self.app_label, schema_editor, old_state,
> project_state)
>   File "d:\git\django\django\db\migrations\operations\models.py", line
> 557, in database_forwards
> getattr(new_model._meta, self.option_name, set()),
>   File "d:\git\django\django\db\backends\base\schema.py", line 345, in
> alter_index_together
> self._delete_composed_index(model, fields, {'index': True},
> self.sql_delete_index)
>   File "d:\git\django\django\db\backends\base\schema.py", line 358, in
> _delete_composed_index
> ", ".join(columns),
> ValueError: Found wrong number (0) of constraints for ert_brand(name,
> value)
> }}}
>
> But the problem gets rectified if we migrate the first migration (i.e.
> 0001_initial in this case).

New description:

 I get an error when I run `sqlmigrate` for a migration which drops an
 `index_together` constraint until actually migrating the previous
 migration. It happens for postgres and not for sqlite.

 Steps to reproduce the bug:

 1) Create app with the following models:
 {{{
 #!python
 from django.db import models

 class Brand(models.Model):
 name = models.CharField(max_length=100, db_index=True)
 value = models.IntegerField(blank=True, null=True, default=0)

 class Meta:
 index_together = (
 ('name', 'value'),
 )
 }}}

 Run `python manage.py makemigrations`.
 Then see the sql statements using `python manage.py sqlmigrate 
 0001_initial`.
 Everything works fine.

 2) Remove the `index_together` part (and the whole `Meta` class).

 Now run `python manage.py makemigrations`.
 Then see the sql statements using `python manage.py sqlmigrate 
 ` and an error is thrown.

 {{{

 Traceback (most recent call last):
   File "manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "d:\git\django\django\core\management\__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "d:\git\django\django\core\management\__init__.py", line 359, in
 execute
 se

[Django] #26624: Error when running sqlmigrate after dropping index (of index_together) without actually migrating

[Django]

#26624: Error when running sqlmigrate after dropping index (of index_together)
without actually migrating
+--
 Reporter:  akki|  Owner:  
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  master
 Severity:  Normal  |   Keywords:  sqlmigrate index
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 I get an error when I run `sqlmigrate` for a migration which drops an
 `index_together` constraint until actually migrating the previous
 migration.

 Steps to reproduce the bug:

 1) Create app with the following models:
 {{{
 #!python
 from django.db import models

 class Brand(models.Model):
 name = models.CharField(max_length=100, db_index=True)
 value = models.IntegerField(blank=True, null=True, default=0)

 class Meta:
 index_together = (
 ('name', 'value'),
 )
 }}}

 Run `python manage.py makemigrations`.
 Then see the sql statements using `python manage.py sqlmigrate 
 0001_initial`.
 Everything works fine.

 2) Remove the `index_together` part (and the whole `Meta` class).

 Now run `python manage.py makemigrations`.
 Then see the sql statements using `python manage.py sqlmigrate 
 ` and an error is thrown.

 {{{

 Traceback (most recent call last):
   File "manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "d:\git\django\django\core\management\__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "d:\git\django\django\core\management\__init__.py", line 359, in
 execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "d:\git\django\django\core\management\base.py", line 305, in
 run_from_argv
 self.execute(*args, **cmd_options)
   File "d:\git\django\django\core\management\commands\sqlmigrate.py", line
 33, in execute
 return super(Command, self).execute(*args, **options)
   File "d:\git\django\django\core\management\base.py", line 356, in
 execute
 output = self.handle(*args, **options)
   File "d:\git\django\django\core\management\commands\sqlmigrate.py", line
 62, in handle
 sql_statements = executor.collect_sql(plan)
   File "d:\git\django\django\db\migrations\executor.py", line 177, in
 collect_sql
 state = migration.apply(state, schema_editor, collect_sql=True)
   File "d:\git\django\django\db\migrations\migration.py", line 129, in
 apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "d:\git\django\django\db\migrations\operations\models.py", line
 557, in database_forwards
 getattr(new_model._meta, self.option_name, set()),
   File "d:\git\django\django\db\backends\base\schema.py", line 345, in
 alter_index_together
 self._delete_composed_index(model, fields, {'index': True},
 self.sql_delete_index)
   File "d:\git\django\django\db\backends\base\schema.py", line 358, in
 _delete_composed_index
 ", ".join(columns),
 ValueError: Found wrong number (0) of constraints for ert_brand(name,
 value)
 }}}

 But the problem gets rectified if we migrate the first migration (i.e.
 0001_initial in this case).

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.fc3b3f00675563892b33953eb01ffe40%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25643: Allow update() with aggregates and joins via subqueries

[Django]

#25643: Allow update() with aggregates and joins via subqueries
-+-
 Reporter:  jorgecarleitao   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mjtamlyn):

 * cc: mjtamlyn (added)


Comment:

 Agreed this would be great. For what it's work, `update .. from ..`
 definitely works in PG as well.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.1bf0bc93e31a7afdd5ec82b61b5b9a41%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26623: Customizing environment variable for for RemoteUserMiddleware requires subclass

[Django]

#26623: Customizing environment variable for for RemoteUserMiddleware requires
subclass
--+--
 Reporter:  adelton   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by adelton):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Proposed patch at https://github.com/django/django/pull/6616.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.17ea8f04682de0bffa340139ef3adbfb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26623: Customizing environment variable for for RemoteUserMiddleware requires subclass

[Django]

#26623: Customizing environment variable for for RemoteUserMiddleware requires
subclass
--+
 Reporter:  adelton   |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.auth  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Currently, when deploying Django project and the environment variable for
 external authentication is different than the default `REMOTE_USER` like
 in environment behind HTTP proxy environment where the data comes in HTTP
 request headers and is seen as `HTTP_REMOTE_USER` or `HTTP_X_REMOTE_USER`,
 the way to "configure" Django is to subclass the `RemoteUserMiddleware` or
 `PersistentRemoteUserMiddleware`.

 Coding the configuration with a class and then enabling it in
 `settings.py` is a hurdle especially in devops environments.

 Since the `RemoteUserMiddleware` already depends on externally set
 environment variable for operation, here's a proposal to make the
 environment variable name externally configurable as well, with
 `DJANGO_REMOTE_USER_VAR`. That way the specifics of the external
 environment can be configured in the configuration of that external
 environment, like Apache HTTP Server configuration, without the admins
 having to work with Python code. I propose update of the
 `RemoteUserMiddleware` behaviour because that way it can be consumed by
 subclasses as well.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.9aa6c1bb27b43961593376721f7c1d14%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.