After invalidateSession I'm able to access secured endpoint with "invalidated" session

Hello

Looks like the invalidateSession function doesn’t invalidate the session as it should. I’ll explain below what I mean. If you want to look at steps to reproduce without technical details, scroll to the end 😃

I use “com.softwaremill.akka-http-session” %% “core” % “0.4.0” with Scala version 2.12.1

I use following configs for session:

session {
  server-secret = "YzszrU1UkqsMqCNEnuLI8DDWs6Wqacj2z4dbtquSjB8GbsFpBA7GG38yk0DaIyrB"
  encrypt-data = true
  header {
    send-to-client-name = "Set-Authorization"
    get-from-client-name = "Authorization"
  }
}

Here is my session serialization (de-)

case class Session(role: String, email: String)
object Session {
implicit def serializer: SessionSerializer[Session, String] =
  new MultiValueSessionSerializer[Session](
    (session => Map(
      "role" -> session.role,
      "email" -> session.email)),
    (map => Try {
      Session(
        map.get("role").get,
        map.get("email").get)
    })
  )
}

And finally routes:

val routes = path("login") {
post {
  entity(as[Credentials]) { credentials =>
    onSuccess(userActor ? Authenticate(credentials)) {
      case loggedIn: LoggedIn => {
        setSession(oneOff, usingHeaders, Session(loggedIn.user.role, loggedIn.user.email)) {
          complete(HttpResponse(StatusCodes.OK))
        }
      }
      case noSuchEmail: NoUserWithEmail => complete(HttpResponse(StatusCodes.BadRequest))
      case InvalidPassword => complete(HttpResponse(StatusCodes.BadRequest))
    }
  }
}
} ~ path("me") {
get {
  requiredSession(oneOff, usingHeaders) { session =>
    complete(session.role)
  }
}
} ~ path("logout") {
post {
  requiredSession(oneOff, usingHeaders) { session =>
    invalidateSession(oneOff, usingHeaders) {
      complete(HttpResponse(StatusCodes.OK))
    }
  }
}
}

Here is what I do:

1. Call POST /login and receive back in the header long_encrypted_token_A
2. Call GET /me with the long_encrypted_token_A header and receive back appropriate response with ADMIN value
3. Call POST /logout and receive back 200 response (here I assume that the session is invalidated)
4. Call GET /me with the long_encrypted_token_A header and receive back appropriate response with ADMIN value

So the question:

Why I can still successfully can use the token after invalidation?

Thanks

[adamw]

Yes. That’s why sessions should always have an expiry date 😃 Optionally refreshed with the refresh token - which assumes external storage and “global” invalidation.

[adamw]

@kormoglaz so you are saying that the token is not removed from storage? That should happen … maybe you can try with a copy of InMemoryRefreshTokenStorage and with some debugging statements added.

Btw. this storage isn’t mean for production, only for testing. It’s not thread-safe (but making it such wouldn’t be hard, just a different Map implementation)