Re: django.contrib.auth CLI

[Adam Johnson]

This sounds like it could be useful but not sure how many projects manage
their Django users through config management commands like this.

Whilst you say it would be useful in core, if you had a concrete
implementation in a third party app that would provide more to talk about,
and allow you to solve your problem for the current project?

There are also probably some other commands that could have idempotent
modes, maybe loaddata?

On Wed, 10 Oct 2018 at 11:58, Jamesie Pic  wrote:

> Hi all,
>
> Currently, django has user management commands createsuperuser and
> changepassword
> ,
> which allow to automate some user management with an automated
> Configuration Management (CM) tool, such as Ansible.
>
> For example, you have a list of users in an a site-specific configuration
> data repository, ie. of yaml files. You can program your CM can iterate on
> it to create super users (example
> 
> ).
>
> The only issue is that it will choke when trying to create duplicates so
> that's one thing I'd like to request comments about with the purpose of a
> patch proposal to provide an idempotent command (example
> ). Another possibility to achieve
> idempotence is to use another username list.
>
> However what happens when a user leaves the team is that we add them to
> another list, "remove_users" (example
> ).
> Our CM will iterate over those, and delete the users. It would be easier
> with a CLI command to drop a user /by login name/.
>
> Yes of course we can stack some statements with semi colons, injecting
> code into stdin of the django-admin shell command, and create a juicy
> one-liner. I've been doing that for a while myself (some years), over
> again, so if you're open to contributions I can direct some of that energy
> upstream instead of in my own one-liners / deployment recipes.
>
> I don't think this is a good candidate for being in an external app in my
> opinion because the CM recipe should work with a Django fresh project, and
> not require to install an extra app, hence the "containing it in a
> one-liner".
>
> Thanks for reading,
>
> Have a great day
>
> --
> ∞
>
> --
> 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/CAC6Op1_2iuRVFonCsYFhNZEfTfwfqEJB4PC0upjtYMzphvKXzg%40mail.gmail.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/CAMyDDM3PEb%2BZZsaTm8U70R8GvoQ-iGRr1JLdippD6nA2Sj%3Dycw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Requiring sqlparse for sqlite introspection

[Tim Graham]

sqlparse is already installed as part of Django's tests. The question is 
whether sqlparse should be mandatory for SQLite users (i.e. when getting 
started with a new project an error message will say, "You must install 
sqlparse to use SQLite" (I don't think there's a way to install it 
automatically unless we install it for all users, regardless of database) 
or if we should try to make it optional and only raise an error if a 
project's migrations require it.

The question is "what percentage of SQLite projects are going to end up 
needing sqlparse based on their migrations? If it's high enough, it might 
make for a better user experience to have users install it when they're 
getting started instead of a lazy error when get_constraints() is called."

On Monday, October 8, 2018 at 3:22:32 AM UTC-4, Andrew Godwin wrote:
>
> Adding sqlparse into the introspection code for SQLite specifically means 
> it's going to be a runtime dependency for anything to do with migrations.
>
> I'm alright having that be the case, but I do think we should make sure 
> the tests run with SQLite as otherwise a large section of the most 
> complicated code in migrations won't be tested properly.
>
> Andrew
>
>
> On Mon, 8 Oct 2018, 00:59 Ian Foote, > wrote:
>
>> Hi all,
>>
>> On my pull request (https://github.com/django/django/pull/10406) 
>> refactoring how Django creates database constraints I introduced a 
>> dependency on sqlparse in the sqlite introspection code. This allows Django 
>> to correctly read information about constraints on sqlite, particularly the 
>> name.
>>
>> When reviewing (
>> https://github.com/django/django/pull/10406#issuecomment-424542217) Tim 
>> Graham raised the question of whether we should make sqlparse a mandatory 
>> requirement for the sqlite tests or if we should skip those tests that 
>> require it. In later discussion (
>> https://github.com/django/django/pull/10406#issuecomment-427362983), Tim 
>> raised the point that the introspection code is used by migrations.
>>
>> I'm not clear myself what the best route forwards here is, so I'm 
>> bringing it to Django Developers for discussion (as Tim suggested). 
>>
>> Thanks,
>> Ian
>>
>> -- 
>> 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/CAFv-zfKadOeWit8M6GMmx4H2ChUCU6u%3DscHX8F7oBKJkHRbuVg%40mail.gmail.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/9a5822a0-18c7-4fef-b1d6-b09e9bb63805%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Standalone is_safe_url() function

[ivan via Django developers (Contributions to Django itself)]

Hi Markus,

Well, adding new requirements for every function might be not a scalable 
approach, but if some stuff in django important for security was separated 
into a sub-project it could allow more people to patch their projects more 
easily. From what I've seen in various projects I worked in, far too many 
folks don't update django (and other deps) often enough because their fear 
that something will break (and it often does when custom code depending on 
django internals is involved), keeping some parts of the django codebase in 
a separate but official package could make it easier for many projects to 
update just it without worrying, provided that package's api is absolutely 
stable and backward-compatible. People who run unsupported versions of 
django (I don't approve but it's a reality we have to deal with) could also 
benefit from it as they can update the package regardless of which version 
of django itself they use.

The major downsides, it seems to me, are that people might get even 
sloppier with updating django if they think that security sub-package is 
enough to stay safe (it should be made clear that it's not) and that it 
adds an additional dependency (but I think it's ok as long as it's just one 
and its purpose and contents is obvious). Also it would be hard to decide 
what to leave in django and what to separate.

tl;dr what I'm saying is I'm not against moving it from django to a 
separate package django will depend on, but I'd prefer it having a broader 
goal than one function, however important.

Also, I tried to look up documentation for `is_safe_url()` and failed. Is 
there any particular reason why it's not documented? You can see seven 
other things 
in https://docs.djangoproject.com/en/2.1/ref/utils/#module-django.utils.http 
but not a single mention of is_safe_url...

Ivan.

On Wednesday, October 10, 2018 at 1:06:46 PM UTC+3, Markus Holtermann wrote:
>
> Hi all, 
>
> Django provides a function `django.utils.is_safe_url()` to ensure that a 
> given URL (absolute or relative) is safe to redirect to. I needed that 
> functionality on another project that doesn't use Django at all. I thus 
> built a standalone is-safe-url Python package that can be installed from 
> PyPI and exposes exactly that functionality: 
>
>   $ pip install is-safe-url 
>   Collecting is-safe-url 
> Downloading https://files.pythonhosted.org/packages/7a/c3 
>  
> /40c363bc4c3d0ddcda3489239ba64752b8c18cb6493e058f8f1b73154925/is_safe_url-1.0-py3-none-any.whl
>  
>
>   Installing collected packages: is-safe-url 
>   Successfully installed is-safe-url-1.0 
>
> The code is available on GitLab: https://gitlab.com/MarkusH/is_safe_url 
>
> I'd love to get some feedback on a couple of things: 
>
> - As Django is published under the BSD-3 clause license, the standalone 
> package is published under the same license. I'd love some feedback if the 
> package adheres to the required references and naming of the source. 
>
> - I added a note that security issues should be reported privately to the 
> Django security team at secu...@djangoproject.com  or me 
> personally (I'm a member of the security team and could forward the report 
> accordingly). Are there suggestions how the statement in the README could 
> be made more clear? 
>
> - The package is available for Python 2.7, 3.4, 3.5, 3.6, and 3.7. Should 
> I keep 2.7 or drop it? I know some people are still on 2.7 and 2.7 is still 
> supported for another 2 years. 
>
> - How would security releases work? When there's a security report against 
> Django's built-in is_safe_url(), this package would need to be released as 
> well. 
>
> - Jannis Leidel raised a valid concern about abandonment of this or 
> similar packages (thanks!): "I'm mostly worried about abandonment of 
> packages (from experience) that makes maintenance of sec infrastructure 
> brittle." — https://twitter.com/jezdez/status/1049955307558981634 
>
> I want to approach the latter concern about abandonment upfront. But I 
> don't have a clear answer or solution to it yet. 
>
> - Would it be useful to have this package under the Django GitHub org? 
> - If so, should Django possibly depend on that package by itself? Given 
> how often Django had security releases because of issues in `is_safe_url()` 
> releasing a smaller package and not the full Django package could possibly 
> be beneficial. 
> - Does somebody from the security team want or should be another 
> maintainer? 
>
> Thanks for reading. 
>
> Markus 
>

-- 
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 

Fellow Reports - October 2018

[Tim Graham]

Week ending October 6, 2018


Triaged

---

https://code.djangoproject.com/ticket/29806 - Add parent_link to ForeignKey 
(duplicate)

https://code.djangoproject.com/ticket/29807 - Custom user model with 
SlugField username causes `allow_unicode` error in admin (invalid)

https://code.djangoproject.com/ticket/29811 - Admin: Extend the Object 
History to Table History (wontfix)

https://code.djangoproject.com/ticket/29812 - AlterUniqueTogether creates 
invalid SQL for app with hyphen in name (duplicate)

https://code.djangoproject.com/ticket/29808 - Applied migration detection 
may fail when using a case-insensitive collation (accepted)

https://code.djangoproject.com/ticket/29814 - Allow serializing NoneType in 
migrations (accepted)

https://code.djangoproject.com/ticket/29823 - Incorrect Decimal handling in 
Sum queries (accepted)

Reviewed/committed

--

https://github.com/django/django/pull/10457 - Fixed #29804 -- Added 'did 
you mean' suggestions for unsupported lookup error.

https://github.com/django/django/pull/10386 - Fixed #29711 -- Added a 
system check for uniquness of admin actions' __name__.

https://github.com/django/django/pull/10415 - Fixed #29598 -- Deprecated 
FloatRangeField in favor of DecimalRangeField.

https://github.com/django/django/pull/10378 - Fixed #29745 -- Based 
Expression equality on detailed initialization signature. 

https://github.com/django/django/pull/10418 - Fixed #29729 -- Updated the 
contributing tutorial to use an imaginary ticket.

https://github.com/django/django/pull/10475 - Fixed #29775 -- Fixed URL 
converters in a nested namespaced path.

https://github.com/django/django/pull/10414 - Improved tone in 
docs/ref/settings.txt.

-- 
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/257f7c67-34fe-48c0-bb27-b3e3bb5b16c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django.contrib.auth CLI

[Jamesie Pic]

Hi all,

Currently, django has user management commands createsuperuser and
changepassword
,
which allow to automate some user management with an automated
Configuration Management (CM) tool, such as Ansible.

For example, you have a list of users in an a site-specific configuration
data repository, ie. of yaml files. You can program your CM can iterate on
it to create super users (example

).

The only issue is that it will choke when trying to create duplicates so
that's one thing I'd like to request comments about with the purpose of a
patch proposal to provide an idempotent command (example
). Another possibility to achieve
idempotence is to use another username list.

However what happens when a user leaves the team is that we add them to
another list, "remove_users" (example
).
Our CM will iterate over those, and delete the users. It would be easier
with a CLI command to drop a user /by login name/.

Yes of course we can stack some statements with semi colons, injecting code
into stdin of the django-admin shell command, and create a juicy one-liner.
I've been doing that for a while myself (some years), over again, so if
you're open to contributions I can direct some of that energy upstream
instead of in my own one-liners / deployment recipes.

I don't think this is a good candidate for being in an external app in my
opinion because the CM recipe should work with a Django fresh project, and
not require to install an extra app, hence the "containing it in a
one-liner".

Thanks for reading,

Have a great day

-- 
∞

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

Standalone is_safe_url() function

[Markus Holtermann]

Hi all,

Django provides a function `django.utils.is_safe_url()` to ensure that a given 
URL (absolute or relative) is safe to redirect to. I needed that functionality 
on another project that doesn't use Django at all. I thus built a standalone 
is-safe-url Python package that can be installed from PyPI and exposes exactly 
that functionality:

  $ pip install is-safe-url
  Collecting is-safe-url
Downloading https://files.pythonhosted.org/packages/7a/c3  
/40c363bc4c3d0ddcda3489239ba64752b8c18cb6493e058f8f1b73154925/is_safe_url-1.0-py3-none-any.whl
  Installing collected packages: is-safe-url
  Successfully installed is-safe-url-1.0

The code is available on GitLab: https://gitlab.com/MarkusH/is_safe_url

I'd love to get some feedback on a couple of things:

- As Django is published under the BSD-3 clause license, the standalone package 
is published under the same license. I'd love some feedback if the package 
adheres to the required references and naming of the source.

- I added a note that security issues should be reported privately to the 
Django security team at secur...@djangoproject.com or me personally (I'm a 
member of the security team and could forward the report accordingly). Are 
there suggestions how the statement in the README could be made more clear?

- The package is available for Python 2.7, 3.4, 3.5, 3.6, and 3.7. Should I 
keep 2.7 or drop it? I know some people are still on 2.7 and 2.7 is still 
supported for another 2 years.

- How would security releases work? When there's a security report against 
Django's built-in is_safe_url(), this package would need to be released as well.

- Jannis Leidel raised a valid concern about abandonment of this or similar 
packages (thanks!): "I'm mostly worried about abandonment of packages (from 
experience) that makes maintenance of sec infrastructure brittle." — 
https://twitter.com/jezdez/status/1049955307558981634

I want to approach the latter concern about abandonment upfront. But I don't 
have a clear answer or solution to it yet.

- Would it be useful to have this package under the Django GitHub org?
- If so, should Django possibly depend on that package by itself? Given how 
often Django had security releases because of issues in `is_safe_url()` 
releasing a smaller package and not the full Django package could possibly be 
beneficial.
- Does somebody from the security team want or should be another maintainer?

Thanks for reading.

Markus

-- 
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/1539165995.555224.1537024600.56847611%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.