Re: About secure-auth

[Michael Manfre]

Hi,

This mailing list is for the discussion of developing Django itself.
Questions related to using Django are meant for the django-users mailing
list.

I'm not familiar enough with the MySQLdb python package, but if it supports
that as a connection option, you'd need to provide it under the DATABASES
"OPTIONS" dict in your settings. If it doesn't accept a connection param
that matches --skip-secure-auth, then you'll need to look in to something
to proxy the connection or perhaps extending the mysql database backend.

If you find yourself needing to work on a database backend, check out the
Custom Database Backends talk given at DUTH last year.

Regards,
Michael Manfre

On Sun, Feb 19, 2017 at 8:11 PM  wrote:

How do I tell django to use --skip-secure-auth when connecting to mysql?

049, "Connection using old (pre-4.1.1) authentication protocol refused
(client option 'secure_auth' enabled)")

-- 
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/9ae435f7-d934-47fb-9522-452ae135207e%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBtO4qptk6che_iz%2BRsAARRd9TjSoHKuksFp6jE8Zfxg8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modifying django.db.models.expressions.Func.as_sql() to allow `**extra_context` to be more useful

[Josh Smeaton]

Avoid modifying self in `as_` methods if possible, even if you are going to 
restore state. See how some of the others work around needing to switch 
order etc 
here: 
https://github.com/django/django/blob/75f0070a54925bc8d10b1f5a2b6a50fe3a1f7f50/django/db/models/functions/base.py#L58

Short version: clone self (performance cost I admit), then manipulate the 
clone before rendering it. I think that's enough for the patch you're 
working on. If we want to tackle clone performance then we can do so in 
another patch.


On Monday, 20 February 2017 04:51:18 UTC+11, Adam Johnson wrote:
>
> I don't understand the implications of moving the extra_context line, but 
> is it not possible to reverse the order of the params in as_mysql with 
> something like the following?
>
> def as_mysql(self, compiler, connection):
> self.source_expressions = reversed(self.source_expressions)
> sql, params = self.as_sql(compiler, connection, function='LOCATE')
> self.source_expressions = reversed(self.source_expressions)
> return sql, params
>
> It's a bit hacky but I don't see why it wouldn't work. May be better with 
> a context manager to do the temporary reversal.
>
> On 19 February 2017 at 08:04, > wrote:
>
>> I'm busy working on a patch to add a string index function to the default 
>> database functions: https://code.djangoproject.com/ticket/27834
>>
>> As part of this patch, the arguments passed to the LOCATE MySQL function 
>> need to be in reverse order to all of the other backend implementations. 
>> I've been toying with a few ways to make this as small a code change as 
>> possible, but I don't think that the Func API allows for modification of 
>> something like expression order by the time the backend is known (i.e. in 
>> `as_mysql()`.
>>
>> What are everyone's thoughts on moving this line: 
>> https://github.com/django/django/blob/master/django/db/models/expressions.py#L552
>>  
>> to just before the return statement on line 563? Are there any 
>> repercussions?
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/3975696a-1846-4a20-9c9b-a1cd25625e2a%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/748f3067-66f7-4b31-b71a-bfad290e3399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

About secure-auth

[acamue]

How do I tell django to use --skip-secure-auth when connecting to mysql?

049, "Connection using old (pre-4.1.1) authentication protocol refused 
(client option 'secure_auth' enabled)")

-- 
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/9ae435f7-d934-47fb-9522-452ae135207e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Replacing the contrib.sites Site model with a setting?

[Wim Feijen]

Hi all,

I'm in favour of defining the sites in settings. In addition, it would ease 
transferring db dumps from live to test servers and it would prevent db 
queries.

I wonder, because we define sites in ALLOWED_HOSTS as well, whether we can 
combine these settings. 

For scheme, what are expected values here? As we are moving from http to 
https environments, I wonder: do we still want to define schemes? I prefer 
following server configuration here.

Wim


-- 
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/bdde6046-1e4a-40c2-b772-436e9c7ddc82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels: get IP address of client websocket

[Fabien Millerand]

Just for info, it cannot be emulated in the HttpClient for testing, unlike 
the  regular django one where REMOTE_ADDR='IP_ADDRESS' can be passed

Le dimanche 19 février 2017 20:56:29 UTC+1, Fabien Millerand a écrit :
>
> Got it. Sorry and thanks.
>
>
>
> Le vendredi 17 février 2017 19:22:27 UTC+1, Andrew Godwin a écrit :
>>
>> It's in the connect message, as message['client']: 
>> http://channels.readthedocs.io/en/latest/asgi.html#connection
>>
>> Andrew
>>
>> On Fri, Feb 17, 2017 at 10:05 AM, Fabien Millerand  
>> wrote:
>>
>>> As far as I know I cannot get client websocket public IP address with 
>>> channels.
>>>
>>> I even looked into the sessions and couldn't find anything.
>>>
>>> Did I miss 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/c2f88798-b212-47a2-b058-05b2021787ae%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6e22855d-1df8-4df4-aea3-c02d31e8b228%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels: get IP address of client websocket

[Fabien Millerand]

Got it. Sorry and thanks.



Le vendredi 17 février 2017 19:22:27 UTC+1, Andrew Godwin a écrit :
>
> It's in the connect message, as message['client']: 
> http://channels.readthedocs.io/en/latest/asgi.html#connection
>
> Andrew
>
> On Fri, Feb 17, 2017 at 10:05 AM, Fabien Millerand  > wrote:
>
>> As far as I know I cannot get client websocket public IP address with 
>> channels.
>>
>> I even looked into the sessions and couldn't find anything.
>>
>> Did I miss 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/c2f88798-b212-47a2-b058-05b2021787ae%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cee5236-87ef-41d5-b382-4fba2d5fd049%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Modifying django.db.models.expressions.Func.as_sql() to allow `**extra_context` to be more useful

[Adam Johnson]

I don't understand the implications of moving the extra_context line, but
is it not possible to reverse the order of the params in as_mysql with
something like the following?

def as_mysql(self, compiler, connection):
self.source_expressions = reversed(self.source_expressions)
sql, params = self.as_sql(compiler, connection, function='LOCATE')
self.source_expressions = reversed(self.source_expressions)
return sql, params

It's a bit hacky but I don't see why it wouldn't work. May be better with a
context manager to do the temporary reversal.

On 19 February 2017 at 08:04,  wrote:

> I'm busy working on a patch to add a string index function to the default
> database functions: https://code.djangoproject.com/ticket/27834
>
> As part of this patch, the arguments passed to the LOCATE MySQL function
> need to be in reverse order to all of the other backend implementations.
> I've been toying with a few ways to make this as small a code change as
> possible, but I don't think that the Func API allows for modification of
> something like expression order by the time the backend is known (i.e. in
> `as_mysql()`.
>
> What are everyone's thoughts on moving this line:
> https://github.com/django/django/blob/master/django/db/model
> s/expressions.py#L552 to just before the return statement on line 563?
> Are there any repercussions?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/3975696a-1846-4a20-9c9b-a1cd25625e2a%
> 40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0mkbppGiW362ACEErjm29AfLGqGvipfcP_jrHzKHi4cg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Modifying django.db.models.expressions.Func.as_sql() to allow `**extra_context` to be more useful

[melinbrad]

I'm busy working on a patch to add a string index function to the default 
database functions: https://code.djangoproject.com/ticket/27834

As part of this patch, the arguments passed to the LOCATE MySQL function 
need to be in reverse order to all of the other backend implementations. 
I've been toying with a few ways to make this as small a code change as 
possible, but I don't think that the Func API allows for modification of 
something like expression order by the time the backend is known (i.e. in 
`as_mysql()`.

What are everyone's thoughts on moving this line: 
https://github.com/django/django/blob/master/django/db/models/expressions.py#L552
 
to just before the return statement on line 563? Are there any 
repercussions?

-- 
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/3975696a-1846-4a20-9c9b-a1cd25625e2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

[Adam Johnson]

+1 for more obvious errors, silently changing the behaviour could indeed
lead to unconsidered security holes like

{% if user is None %}
non-sensitive information
{% else %}
sensitive information
{% endif %}

...which doesn't seem like an unrealistic template snippet. We all know
variables can go missing in refactorings.

Another option, perhaps not feasible to implement, would be deprecating the
old behaviour, similar to the previous change in url with something like:

{% load undefined_vars from future %}

On 17 February 2017 at 23:34, Tim Graham  wrote:

> After reviewing the pull request, I wonder if it would be better to raise
> exceptions when comparing nonexistent variables in {% if %} rather than
> altering the behavior. For existing projects, this would prevent possible
> inadvertent information leakage if some {% if %} starts evaluating
> differently than it did before. While the current behavior may not be
> documented, it seems risky to silently change it.
>
> There are examples of that behavior change on the PR:
> https://github.com/django/django/pull/7901
>
>
> On Saturday, January 7, 2017 at 12:21:33 PM UTC-5, Tim Martin wrote:
>>
>> On Friday, 6 January 2017 10:15:22 UTC, Alasdair Nicol wrote:
>>>
>>> Hi,
>>>
>>> On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote:



 On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:
>
> Hi Tim,
>
> On 01/04/2017 03:39 PM, Tim Martin wrote:
>
> > 1) There are test cases where we have templates that should treat "x
> >is y" as True where x and y are both undefined.
>
> Really? Is this an accidental side effect of some historical change,
> or
> really the intent of the test? That behavior seems buggy to me; more
> likely to be a bug-magnet than useful.
>

 There are a couple of test cases in test_if.py:
 test_if_is_both_variables_missing and 
 test_if_is_not_both_variables_missing.
 These are verifying this specific case, so they haven't been introduced by
 accident. I haven't got as far as figuring out whether it was a fully
 thought through decision or whether someone just created these cases for
 completeness.

>>>
>>> I added the tests in ticket 26479 (see comment 5 onwards) [1]. I believe
>>> I added them for consistency with == and != operators, which have similar
>>> tests [2], [3] (trickier to spot because they are numbered). I apologise if
>>> adding the tests has made it harder to improve the behaviour of the tag.
>>>
>>
>> Thanks for the background info Alasdair, that saved me lots of time
>> hunting around.
>>
>> I agree you were right to add the tests, which were useful since without
>> them I wouldn't have realised the potential behaviour change I was
>> introducing. As I see it, these tests don't in themselves form a reason not
>> to change the behaviour (since AIUI you originally added them for
>> completeness, rather than because this specific behaviour was desired).
>>
>> Does anyone think changing the behaviour of {% if a is None %} is the
>> wrong thing to do? I realise there can potentially be template code out
>> there relying on this, but after a quick scout through the documentation I
>> can't see anywhere that the behaviour on undefined variables is specified
>> officially.
>>
>> For what it's worth, the same issue doesn't come up with ==, because
>> although the existing template behaviour has the same pattern, it's
>> possible to override == and != so that the Undefined object gives the same
>> behaviour as None did before. It's only for 'is' that this can't be
>> achieved. I don't know how for to go with this: preserving the existing ==
>> behaviour but changing it for 'is' leaves the two operations superficially
>> inconsistent (though there's nothing fundamentally wrong with two things
>> that satisfy equality but not 'is'). I can see a couple of alternatives (in
>> all cases all variables are undefined):
>>
>> * "x is y" is false, but "x == y" is true and "x != y" is false (minimal
>> difference from the current behaviour)
>> * "x is y" and "x == y" are both false, "x != y" is true (probably the
>> most mutually consistent?)
>> * "x is y", "x == y" and "x != y" are all false (the SQL NULL alternative
>> - I'm not sure if I like this, but it has the merit that wrongly skipping
>> sections of a template is usually less bad than wrongly including parts of
>> a template)
>>
>> Tim
>>
>>
> --
> 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/76adf765