Paul Taylor Paul Taylor - 1 year ago 157
AngularJS Question

Manage session state across redirects

I have an AngularJS single page app which works with an IdentityServer3 SSO service for authorisation / authentication and a .NET Core WebApi service layer that provides access to data and business logic.

Normally, after the user logs in, the application redirects to the web home page. However, in some circumstances, I need the application to return to a different url. According to the developers, IdentityServer3 cannot do this, therefore the requirement must be handled by the application. They suggest using session storage to persist a redirect url from before the app takes the user to the SSO site for authentication, until it returns, when it should retrieve the stored url and redirect the user to it.

With this in mind, I wrote a WebApi controller to persist the url:

public class RedirectController : Controller
private const string _redirectKey = "RedirectUrl";

// GET: api/redirect
public string Get()
return HttpContext.Session.GetString(_redirectKey);

// POST api/redirect
public void Post([FromBody]string url)
HttpContext.Session.SetString(_redirectKey, url);

// DELETE api/redirect/
public void Delete()

and methods in the SPA to set and retrieve the url:

//to initiate authorisation
$scope.logIn = function () {
var url = $config.webRoot + "/#/myurl";
redirectService.setRedirectUrl(url).then(function (success) {
if (success) {

//after authorisation
authorisationService.processTokenCallbackAsync(hash).then(function () {
//check if the app has set a redirect url for this session
redirectService.getRedirectUrl().then(function (url) {
$window.location.href = url || $config.webRoot + "/#/";
}, function (error) {
$log.error(error && error.message || error);

However, the session is ended when the app navigates to the SSO site. When it comes back, the SessionID is different. Is it possible to get the session state to persist across the SSO redirection, and if so, how do I do it?

Answer Source

I believe you misinterpreted what Brock Allen meant in the reply of the GitHub Issue you provided.

What I believe is that he was referring to the browser session storage and not to to some kind of server side session.

Server side sessions breaks the purpose of a RESTful API, and I do not see any advantages in using them.

Session storage is entirely client-side, and lets you store information until the browser is closed (or the session ends):

sessionStorage.setItem('key', 'value');

And retrive it with: