ASP.Net分阶段升级网站

Question

Simply I want to move development to .Net Core and Angular.

We have a legacy web site project written in C# ASP.Net application, functionally it meets the business needs, performance is good and it runs on the latest technologies. That said it is difficult to work with it, making changes takes time , it really needs an overhaul in the business layer , DAL needs to move to (EF) and want to move to a new GUI framework. These changes are all to improve quality, developer productivity, ultimately accelerate releases.

We have set of new features that need to be implemented, they are almost standalone "bolt-ons", ideal to develop as a separate site, but we need to use existing login details and session details, to make the user experience seamless. The goal is write new functionality in the "new world" and then re-write legacy pages in chunks.

This must be a common and obvious problem but research on how to achieve this have been fruitless.

The question really is how to dynamically share session data between sites.

Answer 1

It sounds like you're currently keeping your session in data in memory. The standard way to get around this is to move your session state out of memory and into something like SQL Server, MongoDB, Redis, etc so that both applications can access the shared state.

Update

Now we're getting to the crux of the problem. If you're depending on data that's stored in fields / hidden fields, you might already have a security problem (it's hard to say without knowing more about your implementation).

I'm guessing that the question you're trying to ask is, "How do I securely navigate from the legacy system to the new system (and vice-versa)". There are a couple of possible strategies here:

• The first solution that comes to mind is an SSO (Single Sign On) approach. This is where you pass an opaque token from one system to the other that identifies the current user.
• If you've able to serve the old/new applications from the same hostname you can use cookies to to store a user token of some sort.

Notes:

• Don't pass something like a plain text user id being passed in the url.
• The SSO token should be something completely separate from the user id (could be a guid that refers to a record in a shared database for example).