Yeah, it can be pretty useful at times, for example, in api clients. I used it quite a few times and had no idea it's not a part of the public api.
Ivan. On Sun, Oct 28, 2018 at 12:29 PM Adam Johnson <m...@adamj.eu> wrote: > I needed that functionality on another project that doesn't use Django at >> all. >> > > If this was my own project, I would have installed Django and imported the > function. Afaict it doesn't depend on settings or any other setup so it > should work from an import. The only concern would be size of site-packages > but that's rarely an issue with web projects. Was there something else that > stopped this? > > - 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. > > > This seems like the start of a broader request for unbundling other things > from Django - if we unbundle this one function, shouldn't we npm-style > unbundle "all the things"? (e.g. cached-property has been > 'unbundled'/forked by PyDanny, Django could start depending on that > version...). But unbundling increases maintenance work, testing complexity, > and the number of things users need to understand. > > 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... >> > > Being undocumented, is_safe_url isn't part of Django's public API. It > could probably be documented now at least, given its utility outside of the > places Django uses it. > > On Wed, 10 Oct 2018 at 18:09, ivan via Django developers (Contributions to > Django itself) <django-developers@googlegroups.com> wrote: > >> 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 >> https://groups.google.com/d/msgid/django-developers/e69d9045-af36-4984-a2a9-60a3a92408be%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/e69d9045-af36-4984-a2a9-60a3a92408be%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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/CAMyDDM1UvkSiufHyq8Rg2c%2B%2Bj8t16AHwqXDzLggJHs9XopU7WA%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM1UvkSiufHyq8Rg2c%2B%2Bj8t16AHwqXDzLggJHs9XopU7WA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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/CADPNjZ6EmiqV_F9LRY2pbM6fq5JhHtt49jGT4VVjYHku6otz4A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
