For ease and cleanliness of reuse, move enforce_csrf from a method to a function

[stevecj]

I would like to raise an MR to deprecate enforce_csrf as a method of SessionAuthentication and make it a standalone function instead. See stevecj@ea64f7f

I was going to simply submit an MR but then read the CONTRIBUTING.md which says I should discuss any proposed change here first.

I ran into a case where it was appropriate to perform CSRF checking with token authentication. I found that there was no particularly clean way to do that. My first try was to copy and paste the whole enforce_csrf method into my TokenAuthentication subclass but that is code duplication and could easily become out of sync with newer versions of DRF.

I then realized that since SessionAuthentication#enforce_csrf does not actually depend on any instance state, I could create an instance of SessionAuthentication and delegate to its .enforce_csrf so that's what I'm doing for now. That assumes, however, that the method does not depend on instance state which I only know by reading the source code. Anyone reviewing the code later is likely to question that and have to waste time looking up the DRF source code again to confirm that it is OK.

Refactoring enforce_csrf to be a standalone function allows reusing it cleanly and with confidence.

[stevecj]

Ping.

[tomchristie]

My first try was to copy and paste the whole enforce_csrf method into my TokenAuthentication subclass but that is code duplication and could easily become out of sync with newer versions of DRF.

I'd recommend that. We don't really want to add any more documented API if at all possible.

[noamcohen97]

@tomchristie
How about making this function a class / static method (noamcohen97@a4de2d6)?

[stevecj]

I like the idea of making it a class or static method.

[tomchristie]

My outlook on this hasn't changed.

[blockchainGuru1018]

I like the idea of making it a class or static method.

I also agree it.