The situation is described in comment:ticket:2210:14 and comment:ticket:2210:16 -- if a user has a browser window to a Trac edit screen open for a long enough time before submitting the edit form, their session can expire and they'll be redirected to the login screen. After successful login, they'll be redirected back to the edit screen, but their edits will be lost, which can be very annoying.
Simple way to reproduce in a browser:
- Log in to your trac site
- Open a browser tab to http://trac-site.com/newticket
- Fill in some text to create the new ticket
- Don't submit the form yet!
- Open a second browser tab to http://trac-site.com/logout and then close it
- Back in the first tab, submit the form
If PermRedirectPlugin is installed, you'll be redirected to the login screen; log in, and you'll land back on the "newticket" form. But all your hard work is completely lost.
I think that it's fair to consider this a bug in PermRedirectPlugin. The reason is that, without PermRedirectPlugin installed, Trac's behavior is "safer." If you follow the exact same reproduction steps without the plugin installed, you'll be given an "Error: Forbidden" screen that prompts you to log in.
This screen is actually rendering an HTTP response to the POST request, rather than instructing the browser to issue an immediate GET request like the plugin does. So this actually gives you an opportunity to log back in using a separate tab, and then simply hit "reload" on the first tab. Your browser will warn you that you're resubmitting a form via POST and ask if you really want to resubmit the data. You say yes, and the exact same POST request will be replayed, with your original intent fulfilled and no loss of data.