We did something similar while building the CMS for the Yahoo! home page. Now the way auth works (and should work), is if you try to access a restricted page and you're not logged in or don't have the necessary privileges, you're redirected to a login page. This is all done automatically by apache and your back end app has no control or knowledge about this.
On the front end, auto-save is done using an XHR call from JavaScript. If we detect a 302 response from the server, and the Location: header was set to a known login pattern, we'd inform the user of this, and allow them to log in in a new window/tab.
On login, the new window/tab redirects the user back to a page in our app. The page in our app does two things.
1. It calls window.opener.someCallback()
2. It calls window.close()
The callback function then makes a call to the server to fetch a new csrf token (you do use csrf tokens, don't you?) and then re-attempts the save.
On the front end, auto-save is done using an XHR call from JavaScript. If we detect a 302 response from the server, and the Location: header was set to a known login pattern, we'd inform the user of this, and allow them to log in in a new window/tab.
On login, the new window/tab redirects the user back to a page in our app. The page in our app does two things. 1. It calls window.opener.someCallback() 2. It calls window.close()
The callback function then makes a call to the server to fetch a new csrf token (you do use csrf tokens, don't you?) and then re-attempts the save.
This reduced user frustration significantly.
I do not know if this app is still in use.