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

[iv...@pwdev.net]

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.

[Adam Johnson]

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.

--
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/e69d9045-af36-4984-a2a9-60a3a92408be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[Ivan Anishchuk]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1UvkSiufHyq8Rg2c%2B%2Bj8t16AHwqXDzLggJHs9XopU7WA%40mail.gmail.com.