For a web app, the client side is javascript in the browser. The server side is

Question

For a web app, the client side is javascript in the browser. The server side is ASP.NET with a REST API. At present there is a single server but we plan to scale out with a server each in the US, UK, and AUS (on Azure). We'll have redis (but that does not sync up instantaneously). They will (almost) always be using SSL.

When a user logs in, we authenticate them. It's easy to pass back the primary key of that user record in the DB and on subsequent calls in, pass that PK to identify the user. It's also trivially easy to then impersonate any user.

What's the best way to implement this? The two things I have thought of are:

1. Return a guid and require that guid on all subsequent calls.
2. Store the PK in the Session data on the server side and use that to identify the user on all subsequent calls.

Both of the above work if an existing session continues to go to the same server (which I believe it does) for each subsequent request.

So, what's the best way to do this? Either of the above two? Or is there another approach that's better?

thanks - dave

Explanation / Answer

In ASP.NET you can keep the session in a data store instead of in memory, this is useful for load balanced deployments. The session can be kept in SQL and I have also found an example of using Redis to store it so retrieval is faster.

So in your case I would use ASP.NET authentication and then use the session to keep the primary key you mentioned in order to recognize the user.

Related Questions

Navigate

• Browse (All)
• Browse F
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.