[slightly reordered]
On 2015-02-04 18:25, Collin Anderson wrote:
> Also, did we decide if the Model-field-layer or Form-field-layer
> would be better?
I think the Form-field layer is definitely the place for it. If I do
my_model.my_text_field = " leading and trailing "
I expect that value to
I'll reply to several emails at once here:
> If we add Origin checking, could we then allow a missing referrer and token?
Yes, we can support the origin header and allow a missing referer.
There's a ticket for that here:
https://code.djangoproject.com/ticket/16010
and I agree that it's long over
I'm certainly leaning on the side of "strip by default" because, like many
others, I feel it's the expected default -- users just don't get it -- and
have been bitten by it before.
I think I'll have a PR for this later tonight...
--
Curtis
On 5 February 2015 at 14:23, charettes wrote:
> Like
Like Russ I think this should be at the form level.
Since both db.CharField and db.TextField use a form.CharField the stripping
implementation should be done there.
I commented here because I recently fixed a related bug in an application I
maintain where a trailing white-space was not striped
Hi All,
I'd be ok with a well thought-out strip-by-default.
- I think most of my problems have been with trailing whitespace on
CharFields.
- I once have seen a minor unintentional leading whitespace. I think I also
may have once used a leading whitespace for sorting purposes, but I'd be ok
wi
Seems to me it would be useful to work with some external projects (like
taggit) to convert their projects to use only public APIs -- otherwise we
are stumbling around in the dark trying to figure out theoretical use cases.
On Monday, February 2, 2015 at 5:41:06 AM UTC-5, Anssi Kääriäinen wrote:
On Wednesday 04 February 2015 11:00:50 Tom Christie wrote:
> > it will be backwards incompatible for every Django installation out
>
> there, but also because throwing away data that the user actually entered
> should be an opt-in, not opt-out behavior.
>
> If adequately called out I think there'
On 02/04/2015 02:00 AM, Tom Christie wrote:
>> it will be backwards incompatible for every Django installation out
> there, but also because throwing away data that the user actually
> entered should be an opt-in, not opt-out behavior.
>
> If adequately called out I think there'd be a valid case t
On Wed, Feb 4, 2015 at 5:59 AM, Erik Romijn wrote:
>
> On 03 Feb 2015, at 16:44, Jon Dufresne wrote:
>> However some URLs are accessed by a unique URL
>> containing a nonce without a login. Login is not an option for these
>> URLs. Sharing this URL is considered very bad and I would like to
>> av
On Tue, Feb 3, 2015 at 11:45 PM, Aymeric Augustin
wrote:
> Le 4 févr. 2015 à 03:31, Jon Dufresne a écrit :
>>
>> Prevent the application from being served in an attacker's iframe: use
>> X-Frame-Options. (Supported by all major browsers [1])
>
> That's irrelevant in the scenario we're discussing
Hi Tim,
Il 04/02/2015 13:24, Tim Graham ha scritto:
Hi Riccardo,
Thanks for the feedback. Maybe adding a link to the patch review
checklist [1] to the contributing tutorial would be sufficient. Most of
the points you've covered are valid and are covered in the rest of the
contributing docs. I'd
Reminder that the 1.8 beta release is scheduled for twelve days from now:
Monday, February 16.
Please check this filter for remaining blockers for beta:
https://code.djangoproject.com/query?status=assigned&status=new&version=1.8alpha1&severity=Release+blocker&or&status=assigned&status=new&keywo
On 03 Feb 2015, at 16:44, Jon Dufresne wrote:
> However some URLs are accessed by a unique URL
> containing a nonce without a login. Login is not an option for these
> URLs. Sharing this URL is considered very bad and I would like to
> avoid it happening unintentionally.
I'm not following this:
I'd really like to be able to define middlewares that actually work in
a well defined and easy to use way. Currently, there is no
guarantee(!) that either process_exception or process_response gets
called after process_request has been called for given middleware, and
this makes it impossible to im
Hi Riccardo,
Thanks for the feedback. Maybe adding a link to the patch review checklist
[1] to the contributing tutorial would be sufficient. Most of the points
you've covered are valid and are covered in the rest of the contributing
docs. I'd like not to duplicate information if possible, but
> leaving a ticket open is a better signal for inviting discussion and
patches.
There's been over 22,000 issues raised in Django's history. It's
understandable and desirable that maintainers close off tickets
aggressively if they don't think they should be tackled.
I wouldn't get too hung up o
On Wednesday, February 4, 2015 at 10:53:28 AM UTC+1, guettli wrote:
>
> Will a patch to provide settings.MIDDLEWARES_INSIDE_TRANSACTION be
> accepted?
>
Most likely not since one of the reasons why @atomic isn't applied via a
middleware (which would then include the middlewares after it) is t
Russell Keith-Magee, 04 Feb 2015 08:26:
> Jacob specifically said a good patch for this feature would be considered
> when he wontfixed #6362.
for me, leaving a ticket open is a better signal for
inviting discussion and patches. when i see a wontfix
closed ticket in other projects it usually mean
Thank you very much for your fast reply.
Our team discussed the solutions we see. At the moment we see this upgrade:
- We stay with the older django version, and don't use atomic for the next
months.
- We provide a patch for django to provide
settings.MIDDLEWARES_INSIDE_TRANSACTION
- I hope
Il 04/02/2015 10:15, Riccardo Magliocchetti ha scritto:
Hello,
I'd like to update the contributing (docs/intro/contributing.txt) docs
to make the process a bit smoother, here's some issues i've found:
- from my own experience it looks like that a pull request is required
for review. Documentati
Hello,
I'd like to update the contributing (docs/intro/contributing.txt) docs
to make the process a bit smoother, here's some issues i've found:
- from my own experience it looks like that a pull request is required
for review. Documentation say patches in the bugtracker are fine but
have be
> it will be backwards incompatible for every Django installation out
there, but also because throwing away data that the user actually entered
should be an opt-in, not opt-out behavior.
If adequately called out I think there'd be a valid case that the current
and future issues it'll be causing
22 matches
Mail list logo
