How to chain redirects in Node/Express - node.js

Question

The behavior I'm trying to achieve is such that when the node app redirects to a URL, once that has been complete, I want the node app to subsequently redirect to another URL.
res.redirect('/hello').then(res.redirect('/'))
Something like that.
What I'm trying to achieve is when a user logs out from my application, they first get redirected to our identity server, which clears any association with the user and the Identity Server, completely logging them out, and then redirect to the application-specific login (a path configured in the node app). Thus,
res.redirect('www.identityserver.com/logout').then(res.direct('www.application.com/auth'))
The restriction is that I can't implement this using the post-logout redirect URL that the identity server is built with... simply because we don't want to upgrade to the latest version. Further - manually clearing their cookies/session in the application and then redirecting them to www.application.com/auth does not fully un-authenticate them. The identity server still knows and associates them with some session/cookie.
NOTE: There's no good answer to this question, but I selected answer with the best effort.

Answer 1

Here's an idea for how to do this.
Change your redirect to a special redirect page of your own. In that redirect page you include an iframe that points to the http://www.identityserver.com/logout page. As long as the logout page does not include anti-framing logic, this should achieve the logout.
Now, since the logout iframe is from a different domain than your page and you don't control it, you cannot communicate with the content of the iframe without cooperation from within the iframe. So, assuming there is no cooperation from the iframe, you are left without a good way to know when the logout is complete. But, you probably don't really need to know that. What you do need to do is to make sure the iframe has enough time to send it's initial request so that the identityserver host can receive that logout request. You can test just how long that might be, but if you start measuring time once this special page has finished loading, then a couple seconds is probably more than enough to make sure the iframe logout request has been sent.
Then, after that couple seconds, you can then redirect your special page to whatever new page you wanted to go to. If you're going to measuring the timing starting from when the page is loaded, then you would want to do this redirect from client-side Javascript in that page by just setting:
window.location = "http://www.application.com/auth";
Now, you don't even have to load a special page to do all this or directly involve the server. You could just create the logout iframe with client-side Javascript and insert it in whatever page you're already in. It can be done either way.
As to your original idea, the concept of two redirects from the same server response is conceptually flawed (which has been mostly explained in comments, but I will summarize here).
A server-side redirect consists of a custom header in the response that specifies the new location to go to and a particular response status that tells the requester that it should do a redirect. By definition, this structure can only hold one redirect. And, once that redirect happens, the browser goes to a new page on a new server and this server has zero influence on that browser any more. So, once you redirect to the logout server, you simply can't influence things any more. It's entirely up to that logout server and the page it provides what happens next.

Answer 2

As the comments above suggest, you probably don't want to do this, but I'm going to answer your question regardless since it might help you understand why.
You could set up a chain of redirects like so:
app.get('/start', function(req, res) {
console.log('start');
res.redirect('/hello');
});
app.get('/hello', function(req, res) {
console.log('hello');
res.redirect('/');
});
app.get('/', function(req, res) {
console.log('/');
res.end();
});
But do note that the redirects here are not really useful at all. Anything the / route ultimately does at the end of the chain could have simply been handled upfront by the /start route, no redirects necessary.