#27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

[Yo-Yo Ma]

I'm not a fan of adding more complexity, for a couple reasons:

1) you have the ['*'] option for local / office development
2) you can just add a record to /etc/hosts to point to the server and then use 
a name like e.g., local-office - just update the record to point to whatever IP 
you're using st the time

-- 
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/c0d5c95a-b978-434f-9ce7-0964cbedae31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#27485 new New feature Allow ALLOWED_HOSTS to accept an IP-range / wildcard

[Thomas Turner]

Hi

The other day I raise a ticket to do with ALLOWED_HOSTS and it was 
suggested that I post on this group before creating a patch
The ticket is https://code.djangoproject.com/ticket/27485

The problem

Now that Django 1.10.3 forces ALLOWED_HOSTS on with debug I have a problem.
The problem is that when I developing I use an ip-address range of 
192.168.1.*. 
The Ip-address can change depending on the computer I use.
so I required the ability to add wildcard partly in an hostname.
ie 
ALLOWED_HOSTS = ['192.168.1.*', '.mydomain.com']
I have seen this solution that doesn't require Django to be changed however 
I don't like it as I feel this could be a security issue
​http://stackoverflow.com/questions/37031749/django-allowed-hosts-ips-range

I happy to do a patch for this. What do people think?

Tom



-- 
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/7c03baf9-8d87-4716-be66-f6a642721a77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Anthony King]

Sending a link to set a password isn't much better.
Perhaps a way to force a password change on login would be better, which
has more use elsewhere, such as being able to periodically force password
changes

On 16 Nov 2016 8:13 p.m., "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I wouldn’t dismiss the idea so quickly. Adding staff users from your
> company is a fairly common use case.
>
> Currently you have to email them a password and ask them to change it.
> This doesn’t set a good example.
>
> The better solution is SSO with the corporate directory (often
> ActiveDirectory or Google Apps), but not every project has taken the time
> to configure that.
>
> Best regards,
>
> --
> Aymeric.
>
> On 16 Nov 2016, at 20:59, Tim Graham  wrote:
>
> I don't think this registration model is common on most websites.
>
> On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da
> Silva wrote:
>>
>> Hello everyone,
>>
>> I have this simple idea that I think django could benefit from, which
>> would be the option to create a user by an invitation from the django admin
>> page. So the person who is creating a new user doesn't have to type a
>> password neither a username for this new user. He would only fill a form
>> with an email that the invitation would be sent to. Something like a reset
>> password link but to add a new user.
>>
>> Do you think it would be useful? That would be accepted as a PR for some
>> version in the future? What are your thoughts?
>>
>> I would like to implement it and contribute to django, but I need
>> feedback from you guys.
>>
>>
>> Thanks!
>>
>> --
>> Bruno Ribeiro da Silva
>> Python Dev and Homebrewer!
>>
>
> --
> 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/2c949269-59f5-4332-8803-
> c2958f789336%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/A7A9A23F-24C3-495D-93C4-
> 12A9B859E9FC%40polytechnique.org
> 
> .
> 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/CALs0z1bNRW072KZNJkkxiU3wjOfELZZ0fP51DJUWiBSX64A%2Bow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Aymeric Augustin]

Hello,

I wouldn’t dismiss the idea so quickly. Adding staff users from your company is 
a fairly common use case.

Currently you have to email them a password and ask them to change it. This 
doesn’t set a good example.

The better solution is SSO with the corporate directory (often ActiveDirectory 
or Google Apps), but not every project has taken the time to configure that.

Best regards,

-- 
Aymeric.

> On 16 Nov 2016, at 20:59, Tim Graham  wrote:
> 
> I don't think this registration model is common on most websites.
> 
> On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da Silva 
> wrote:
> Hello everyone,
> 
> I have this simple idea that I think django could benefit from, which would 
> be the option to create a user by an invitation from the django admin page. 
> So the person who is creating a new user doesn't have to type a password 
> neither a username for this new user. He would only fill a form with an email 
> that the invitation would be sent to. Something like a reset password link 
> but to add a new user.
> 
> Do you think it would be useful? That would be accepted as a PR for some 
> version in the future? What are your thoughts?
> 
> I would like to implement it and contribute to django, but I need feedback 
> from you guys.
> 
> 
> Thanks!
> 
> -- 
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
> 
> -- 
> 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/2c949269-59f5-4332-8803-c2958f789336%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/A7A9A23F-24C3-495D-93C4-12A9B859E9FC%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Feature idea

[Tim Graham]

I don't think this registration model is common on most websites.

On Wednesday, November 16, 2016 at 2:24:43 PM UTC-5, Bruno Ribeiro da Silva 
wrote:
>
> Hello everyone,
>
> I have this simple idea that I think django could benefit from, which 
> would be the option to create a user by an invitation from the django admin 
> page. So the person who is creating a new user doesn't have to type a 
> password neither a username for this new user. He would only fill a form 
> with an email that the invitation would be sent to. Something like a reset 
> password link but to add a new user.
>
> Do you think it would be useful? That would be accepted as a PR for some 
> version in the future? What are your thoughts?
>
> I would like to implement it and contribute to django, but I need feedback 
> from you guys.
>
>
> Thanks!
>
> -- 
> Bruno Ribeiro da Silva
> Python Dev and Homebrewer!
>

-- 
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/2c949269-59f5-4332-8803-c2958f789336%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Feature idea

[Bruno Ribeiro da Silva]

Hello everyone,

I have this simple idea that I think django could benefit from, which would
be the option to create a user by an invitation from the django admin page.
So the person who is creating a new user doesn't have to type a password
neither a username for this new user. He would only fill a form with an
email that the invitation would be sent to. Something like a reset password
link but to add a new user.

Do you think it would be useful? That would be accepted as a PR for some
version in the future? What are your thoughts?

I would like to implement it and contribute to django, but I need feedback
from you guys.


Thanks!

-- 
Bruno Ribeiro da Silva
Python Dev and Homebrewer!

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

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

[Aymeric Augustin]

> On 16 Nov 2016, at 16:35, Mark Young  wrote:
> 
> Once I know the preferred fix, I'll work on the patch.

Unfortunately the hard part is to figure out what the preferred fix is :-/

It's likely to be a trivial one liner. Tests may be a bit more involved.

> One thing I still don't understand is why needs_rollback was set to True in 
> the first place in my simple example.

You should take a look at what the Atomic class does. Database connections 
track in_atomic_block and needs_rollback to allow Atomic to perform its 
function.

-- 
Aymeric.


-- 
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/61127455-B187-4A0D-BF77-21FD8689D492%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

[Mark Young]

Re fixing transaction.rollback: What would be the preferred way to fix 
this? I haven't personally tested it (a coworker has and reports that it 
doesn't work), but BaseDatabaseWrapper.set_rollback requires that 
in_atomic_block be True when set_rollback is called, which is not the case 
in this example or in general, I think (I still don't entirely know what 
in_atomic_block is really supposed to mean). I could manually do 
get_connection(using).needs_rollback = False . 

Once I know the preferred fix, I'll work on the patch. 

One thing I still don't understand is why needs_rollback was set to True in 
the first place in my simple example. Reading the attribute name naively, 
we don't really need to emit a db rollback at all, as the bad save never 
hit the db at all, as it failed in the model validations. (In practice, 
this doesn't matter too much, as there's no real harm in making 
unneeded-as-far-as-the-db-is-concerned rollback calls. Asking more in hopes 
of understanding what's going on better)

Thanks for the help

-- 
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/671da620-cdd9-48ed-9645-258682874117%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DatabaseWrapper.needs_rollback and transaction.rollback()

[Aymeric Augustin]

Hello Mark,

Indeed this is the bug described in https://code.djangoproject.com/ticket/26340 
.

It hasn’t been fixed yet because things become complicated with savepoints and 
because it isn’t obvious that it cannot introduce data corruption bugs.

Perhaps it would make sense to fix the bug at least for the whole transaction 
in rollback() and leave the ticket open for nested transactions with savepoints.

Best regards,

-- 
Aymeric.

> On 16 Nov 2016, at 15:26, Mark Young  wrote:
> 
>  After a validationError occurs, why is the transaction considered dirty, 
> blocking all db reads/writes? In this example: 
> https://bitbucket.org/marky1991/django-test/raw/59c9ff89e4b12b4a831c36171139cb022735201b/test1.py
>  
> 
>  , I don't really expect a TransactionManagementError at all, as the failure 
> in question is a django model ValidationError, so no rollback should be 
> needed, since the save never actually hits the db. At the minimum, however, I 
> would expect a transaction.rollback() to resolve the issue, but it does not. 
> 
> The traceback: https://dpaste.de/ooTy 
> 
> Is there a django bug here or are my expectations not correct?
> 
> I have found this: https://code.djangoproject.com/ticket/26340 
>  , where Aymeric Augustin said 
> that he thought that transaction.rollback should indeed set 
> DatabaseWrapper.needs_rollback to False, as I would expect.
> 
> Thanks
> 
> -- 
> 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/df66a920-2537-48dc-a0e2-4db2de5a54fd%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/18CBF631-B475-41C1-ADFF-27AAFFD1ABE3%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

DatabaseWrapper.needs_rollback and transaction.rollback()

[Mark Young]

 After a validationError occurs, why is the transaction considered dirty, 
blocking all db reads/writes? In this example: 
https://bitbucket.org/marky1991/django-test/raw/59c9ff89e4b12b4a831c36171139cb022735201b/test1.py
 
, I don't really expect a TransactionManagementError at all, as the failure 
in question is a django model ValidationError, so no rollback should be 
needed, since the save never actually hits the db. At the minimum, however, 
I would expect a transaction.rollback() to resolve the issue, but it does 
not. 

The traceback: https://dpaste.de/ooTy

Is there a django bug here or are my expectations not correct?

I have found this: https://code.djangoproject.com/ticket/26340 , where Aymeric 
Augustin said that he thought that transaction.rollback should indeed set 
DatabaseWrapper.needs_rollback to False, as I would expect.

Thanks

-- 
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/df66a920-2537-48dc-a0e2-4db2de5a54fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Tim Graham]

I took a stab at backwards-compatibility with respect to allowing the admin 
to work without adding 'django.forms' to INSTALLED_APPS. It seems to work 
for at least the simple TEMPLATES = 'BACKEND': 
'django.template.backends.django.DjangoTemplates', ...} case, although I'm 
not proud of the code and I'm nervous it's a bit fragile. What do you think 
of the approach? I thought I'd try something to get the conversation going 
again. I've been reacting to some tickets based on the assumption that this 
will get into 1.11 so I'd like to make it happen.

https://github.com/django/django/pull/6498/commits/1eba57277c7168bd491277a14554635bf4efbfc8

On Wednesday, May 18, 2016 at 2:49:52 AM UTC-4, Carl Meyer wrote:
>
> On 05/17/2016 01:33 AM, Claude Paroz wrote: 
> > I can imagine that django.forms would then be responsible to tell the 
> > template engine to add the template source. Maybe this would need a new 
> > API in the template code? 
>
> Yes, it's certainly possible that we could address this with a new API 
> in the template engines. That's a more significant change than I had 
> thought we needed, but it may be the best option. 
>
> I'm happy to work on this issue more, but it's not likely to be until 
> the PyCon sprints. 
>
> Carl 
>
>
>
>

-- 
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/ed0c891a-33f9-4b28-80aa-7a90f2d097e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django.core.file.storage.FileSystemStorage strange behavior

[a . branco]

Hello everyone!

I'm using django 1.9.10. (It is the same on 1.10.x)

After two day tracking an obscure bug I found it in the behavior of 
FileSystemStorage.exists.

I was using django compressor and it store compressed files in the django 
CACHE folder with a random name. It seems that the first random number is 
always the same, so if the file does exists the logic of the Storage class 
generates a second and different number.

In my CACHE folder there was a file named e8c59b724a2d.css, the number is 
the first generated, so I was expecting a generation of a new 
number/filename but it doesn't happened because the file was a link to 
itself (this strange situation was generated during deploy on another 
machine).

The method FileSystemStorage._save try to open file e8c59b724a2d.css and it 
gets the EEXISTS error, it ask for another name with the method 
(Storage).get_available_filename this method in its turn check for the 
existence of the file with (FileSystemStorage).exists, the last method uses 
the os.path.exists that for file e8c59b724a2d.css  (link on itself) returns 
False, in this way (Storage).get_available_filename return the same name 
causing an infinite loop.

Could be FileSystemStorage.exists changed to use os.path.lexists to make it 
more robust?

Thank you.

Alfredo Branco


-- 
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/9425d34d-06f6-48c1-bc7c-bb083005d063%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.