Re: Status of #15619: logout via POST, but not GET

I was just thinking about this. I agree that a GET causing logout is wrong, and we need to not break things and I agree we need to keep the original view untouched so we don't break anything. _maybe_ deprecate it. The admin could begin using the new view right away. On Wednesday, December 3,

Re: Status of #15619: logout via POST, but not GET

>From a brief look, the changes in the pull request do not appear to consider backwards compatibility at all, which would be important. The argument that it's ok because it would now just show a confirmation page is insufficient as if someone had built a confirmation page there would now be two.

Re: Status of #15619: logout via POST, but not GET

I think you're thinking of https://code.djangoproject.com/ticket/17209. The latest patch appears to allow logout via GET, but even it enforced POST, there are still client-side (template) updates required to turn the logout links into form submissions so I think it should be considered an

Re: Status of #15619: logout via POST, but not GET

Wasn't there a PR to turn all the auth views to CBV? That would implicitly enforce the behaviour to POST-only, I would hope. -- Curtis On 4 December 2014 at 09:52, Tim Graham wrote: > Hi Tim, > > There's an open pull request ,

Re: Status of #15619: logout via POST, but not GET

Hi Tim, There's an open pull request , but it was opened over a year ago and has gone stale. Maybe you'd like to review and update it. You can use the patch review checklist:

Status of #15619: logout via POST, but not GET

I've had a couple cases where browser link pre-fetching triggered an unintended logout from my Django app (I haven't fully tracked down the exact combination of triggering conditions, but I suspect they similar to Israel Brewster's CherryPy issue mentioned on comp.lang.python [1]) and was