11–17 of 17 posts
Uhh, don't use the "safe" filter on user data that you're embedding in javascript, as that introduces arbitrary code injection attacks. As for the default representation not being flat like the author needed, you can use the "values_list" method on your queryset. I worry that articles like this lead to "the blind leading the blind". The arbitrary js injection attack enabled by their first example is concerning, and r…
Neat. I guess I'm a little surprised that the Django REST Framework isn't mentioned, since I thought that's the go-to for pretty much everyone for this task. Certainly this post's code is lighter weight if all you need to do is send some data out of Django. https://www.django-rest-framework.org/
Definitely use DRF for this kind of usecases. The problem with his approach is that it'll always expose ALL the fields of a model to the frontend, like hashed passwords, and can come at a performance cost if the queryset was run with `.only("some", "fields")`. This can be tolerable for small projects but it doesn't scale too well on the long term...
Uhh, don't use the "safe" filter on user data that you're embedding in javascript, as that introduces arbitrary code injection attacks. As for the default representation not being flat like the author needed, you can use the "values_list" method on your queryset. I worry that articles like this lead to "the blind leading the blind". The arbitrary js injection attack enabled by their first example is concerning, and r…
See my comment here: https://news.ycombinator.com/item?id=32750266
Just the whole approach gets dangerously close to a big security issue, even if you do it "right".
Or simply use Django's builtin mechanism for that instead of poorly reimplementing it: https://docs.djangoproject.com/en/4.1/ref/templates/builtins...
Thank you for pointing this out, I forgot about this template filter. This unfortunately still wouldn't properly all the data types mentioned in my article (e.g. QuerySets).
Earlier quoted context omitted.
Definitely use DRF for this kind of usecases. The problem with his approach is that it'll always expose ALL the fields of a model to the frontend, like hashed passwords, and can come at a performance cost if the queryset was run with `.only("some", "fields")`. This can be tolerable for small projects but it doesn't scale too well on the long term...
Surely it will only expose the fields you've defined in your Serializer class? https://www.django-rest-framework.org/api-guide/serializers/...
Earlier quoted context omitted.
See my comment here: https://news.ycombinator.com/item?id=32750266
Right, but in another comment you talk about serializing querysets, and I'd be surprised if you can guarantee that no other developer will ever put dangerous data in any of the rows in your queryset. That approach would be building a pretty dangerous foot gun. Just the whole approach gets dangerously close to a big security issue, even if you do it "right".