﻿ticket	summary	type	release	owner	status	created	modified	_description	_reporter
4963	Redirection problem with different hostnames in NAT	defect	0.11	ejucovy	new	2009-04-22T11:12:03+02:00	2015-06-24T05:30:56+02:00	"=== Facts ===
 * Server is named lets say 'herbert' with Trac
 * Server is in a NAT, port 443 is open and forwarded to herbert
 * dyndns account lets say myherbert.dyndns.org
 * Trac 0.11, PermRedirect 2.0, AccountManager 0.2.1dev-r5479

=== What happens ===
 * From inside the NAT, everything works perfect using https://herbert/trac/project
 * From outside, using https://myherbert.dyndns.org/trac/project, is redirected to the login page. After entering the login data, the URL changes to https://herbert/trac/project which leads to a 'page not found' error.
This only happens when PermRedirect Plugin is enabled.
"	angel
10393	POST data is lost after redirect	defect	1.0	ejucovy	new	2012-09-30T04:39:08+02:00	2014-07-26T10:54:40+02:00	"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:
 
 1. Log in to your trac site
 1. Open a browser tab to http://trac-site.com/newticket
 1. Fill in some text to create the new ticket
 1. Don't submit the form yet!
 1. Open a '''second''' browser tab to http://trac-site.com/logout and then close it
 1. 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."	ejucovy
12988	Only redirect if correct action property of PermissionError exception	defect		ejucovy	new	2016-12-10T16:36:44+01:00	2016-12-10T16:36:44+01:00	"Suggested in trac:comment:13:ticket:11513:

{{{#!diff
Index: permredirect/filter.py
===================================================================
--- permredirect/filter.py      (revision 13714)
+++ permredirect/filter.py      (working copy)
@@ -24,7 +24,8 @@
                 return template, data, content_type

             exctype, exc = sys.exc_info()[0:2]
-            if issubclass(exctype, PermissionError):
+            if issubclass(exctype, PermissionError) and \
+                    exc.action and exc.action.isupper():
                 req.redirect(req.href.login())

             try:
}}}"	Ryan J Ollos
