3

For example,

If my app, which is scaled automatically by GCR, has OAuth 2.0 + PKCE authorization code flow against a third party identity provider, can I guarantee that after the user has logged in on the third party's site and is redirected back they are redirected back to the same instance?

If they are not, the new instance they are redirected back to will know nothing about the code_verifier, and authentication will fail.

ndtreviv
  • 3,473
  • 1
  • 31
  • 45
  • Google provides some good information and tutorial on this in the context of WebSockets (but techniques are applicable to all application requiring some sort of session/stream id state): https://cloud.google.com/run/docs/triggering/websockets & https://cloud.google.com/run/docs/tutorials/websockets – masterxilo Apr 30 '22 at 13:37

4 Answers4

7

Cloud Run load balancing does not guarantee landing to the same instance on successive requests for a user (i.e. sticky sessions). Between the two requests, the container might have crashed, scaled down, and scaled up again.

Cloud Run containers are meant to be stateless. So if there are any multi-step authentication, or session IDs you’re storing in your application, you should store such state in external storage (like Cloud Memorystore, Redis, Memcached, or a database).

ahmet alp balkan
  • 42,679
  • 38
  • 138
  • 214
  • Are there any docs on connecting to Memorystore from a Cloud Run-deployed app? I get timeouts simply configuring the redis client with the Memorystore IP and port. (Didn't think it would be that easy!) I'm guessing it's related to VPCs/IAM etc etc? – ndtreviv Aug 30 '19 at 09:05
  • Nevermind - I've just seen this: https://stackoverflow.com/questions/56225375/connect-to-memorystore-from-cloud-run Looks like I'll be using redis labs until Cloud Run supports VCP connections. – ndtreviv Aug 30 '19 at 10:14
2

Since Cloud Run is designed to run "stateless containers" you can not rely on internal state of the application.

You have to save the information to an external storage so any instance can access it.

Pusker György
  • 398
  • 1
  • 11
1

It seems like GCP added a "session affinity" feature to cloud run. It should guarantee that requests from the same user are routed to the same instance.

This will not ensure that your session data is still available tho. Depending on your setup you might still need a Redis or something similar. Also be careful that this feature is right now in the preview stage, which means that no SLAs are in place.

Source: https://cloud.google.com/run/docs/configuring/session-affinity

F.Tepel
  • 140
  • 1
  • 6
0

Session handling for authentication and user preferences will not work as expected in Cloud Run or Any scalable environments.

Because most of the application works with a memory-based implementation to perform this function. However, this implementation is unsuitable for an app that can be served from multiple instances, because the session that is recorded in one instance might differ from other instances.

So you must store it in a commonplace where all the instances refer to the session info.

For Cloud Run available solution as of March 2020,

  • you can spin up Redis on Compute Engine(Costly! of course)

  • You can use a Redis instance from Redis Labs

  • You can use Cloud Firestore. (cheap, but not an efficient solution)

Note: Cloud Firestore is a persistent, distributed, transactional database. Often, it's more appropriate to choose a different storage solution for sessions such as Memcache or Redis as their designs offer much faster operation in this use case.

Here is a doc with an example for Nodejs: https://cloud.google.com/nodejs/getting-started/session-handling-with-firestore

For other known Cloud Run Limitation so far. check here

Bala.Raj
  • 1,011
  • 9
  • 18