Also to directly answer the question, I'm talking abour cursor.execute()
On Thursday, April 28, 2016 at 3:48:21 PM UTC-7, Bryce Drennan wrote:
>
> I'm wondering if we're using the term "global" slightly differently.
>
> Yes, prior to the changes removing converters, Django had these converters
I'm wondering if we're using the term "global" slightly differently.
Yes, prior to the changes removing converters, Django had these converters
globally applied to all mysql connections that it created. However, they
didn't apply to mysql connections created outside of django, nor did django
I just got bitten by this today, finding a duplicate row where I didn't
expect one. I haven't been able to find an existing Django bug.
It's a popular topic on stack overflow:
http://stackoverflow.com/questions/17510261/django-unique-together-constraint-failure
http://dba.stackexchange.com/que
On Thursday, April 28, 2016 at 10:48:02 PM UTC+2, Shai Berger wrote:
>
> The problem with these suggestions is that they create a user object
> during
> checks, and that might be an obstacle for some users (side effects and
> required
> initializer parameters are the two most obvious issues).
On Thursday, April 28, 2016 at 8:07:36 PM UTC+2, Markus Holtermann wrote:
>
> I haven't read the entire thread, did you account for custom user models
> that don't inherit from AbstractBaseUser? Do the system checks stil
> work? A Metaclass certainly would not, would it?
Yeah, we probably would
Right, right and right.
Tim, I somehow missed that suggestion. It is certainly workable.
Markus, Custom user classes which do not inherit AbstractBaseUser are a point
I hadn't considered, and in fact they make my suggestions problematic, leaving
_only_ the checks approach.
However, descriptors
> On 28 Apr 2016, at 20:37, Carl Meyer wrote:
>
> I don't have a clear enough sense of the use-cases for
> autoescape-off to know what the behavior should be in that case. If the
> primary use case is "rendering a template that isn't destined for the
> browser anyway, so doesn't need to be safe",
On 04/28/2016 11:46 AM, Aymeric Augustin wrote:
>> On 28 Apr 2016, at 19:30, Aymeric Augustin
>> wrote:
>>
>> It seems reasonable to assume that the result of rendering with
>> autoescaping enabled is HTML-safe — that’s the reason why
>> autoescaping exists.
>
> Scratch that and let me try again
I haven't read the entire thread, did you account for custom user models
that don't inherit from AbstractBaseUser? Do the system checks stil
work? A Metaclass certainly would not, would it?
Cheers,
/Markus
On Thu, Apr 28, 2016 at 10:56:37AM -0700, Florian Apolloner wrote:
Are errors silence ab
Are errors silence able via SILENCED_SYSTEM_CHECKS? If yes, I am against it
-- this has to be an hard unrecoverable error for security reasons or fully
backwards compatible (I am leaning towards the latter if possible in any
way).
On Thursday, April 28, 2016 at 5:01:04 PM UTC+2, Tim Graham wrot
> On 28 Apr 2016, at 19:30, Aymeric Augustin
> wrote:
>
> It seems reasonable to assume that the result of rendering with
> autoescaping enabled is HTML-safe — that’s the reason why
> autoescaping exists.
Scratch that and let me try again:
It seems reasonable to assume that the result of rende
Hi Carl,
> On 28 Apr 2016, at 19:08, Carl Meyer wrote:
>
> Given that both templating
> languages allow turning off autoescaping (or bypassing it in other
> ways), there's no a priori reason to believe that a string resulting
> from rendering a template is necessarily a safe string.
If we’re fo
Hi Aymeric,
On 04/28/2016 11:02 AM, Aymeric Augustin wrote:
> I just stumbled upon an interesting difference between Jinja2 and the
> Django template language.
>
> |Template.render()| returns a safe string in Django. It's likely an
> accident of the implementation more than a design choice. It ha
Hello,
I just stumbled upon an interesting difference between Jinja2 and the Django
template language.
Template.render() returns a safe string in Django. It's likely an accident of
the implementation more than a design choice. It happens because
NodeList.render() calls mark_safe() on its outpu
Do you think my suggestion of a system check to flag this is unacceptable?
diff --git a/django/contrib/auth/checks.py b/django/contrib/auth/checks.py
index d1b0a44..347ad75 100644
--- a/django/contrib/auth/checks.py
+++ b/django/contrib/auth/checks.py
@@ -73,6 +73,14 @@ def check_user_model(app_co
On Monday 11 April 2016 20:13:02 Florian Apolloner wrote:
> On Monday, April 11, 2016 at 6:57:46 PM UTC+2, Tim Graham wrote:
> > I cannot think of much we could do besides monkey-patching the
> > custom-user model.
>
> I would not call checking and rewriting the class in __new__
> monkey-patching,
On Thursday, April 28, 2016 at 8:37:09 AM UTC+2, Sven R. Kunze wrote:
>
> Am Montag, 25. April 2016 10:38:23 UTC+2 schrieb Florian Apolloner:
>>
>> Absolutely not, what are you basing your justification on?
>>
>
> The fact that I know real cases where this was a security issue. I'd
> rather have
17 matches
Mail list logo