Pagine Web .ASP e .NET .aspx classiche in un'unica applicazione Web ASP.NET

Question

Abbiamo una vecchia app Web scritta in ASP classico. Non abbiamo le risorse per riscrivere l'app.

So che le pagine asp e aspx possono coesistere nella stessa app Web ASP.NET, ma sembra che non sia possibile condividere le variabili Applicazione e probabilmente Session tra questi due gruppi di tipi di estensioni di pagina.

Speravo di fare un nuovo sviluppo in ASP.NET e, in teoria, convertire le pagine ASP Classic come andiamo.

C'è un modo per condividere le variabili IIS tra questi due tipi di pagine Web (oltre a passare le informazioni utilizzando i campi stringa stringa e moduli)?

Answer 1

Non esiste una soluzione straigthforwad per condividere le variabili di sessione tra ASP classico e ASP.NET. Ti consiglierei di mantenere le sessioni in un database, come descritto in questo Microsoft Article. In questo modo sia ASP che ASP.NET possono accedere alle variabili di sessione.

Answer 2

Non è un modo diretto. Potresti considerare l'utilizzo di un back-end del database condiviso per lo stato della sessione.

Answer 3

È possibile creare una semplice tabella nel DB per memorizzare le informazioni sulla "sessione" in. Sia la versione classica che la .net possono leggere e scrivere lì.

Answer 4

Gli unici modi per trasmettere questi dati sono i valori GET/POST, i cookie, il file flat o la memorizzazione dei dati nel database. Non c'è nulla di "Built In" nel framework .Net per farlo.

Answer 5

Ho visto un'altra soluzione oltre a utilizzare il database come titolare di sessione condivisa. Dovrei dire in anticipo che l'utilizzo dell'opzione database è probabilmente molto meglio di questo. Ma ...

È possibile creare una pagina ASP la cui unica funzione è quella di archiviare e recuperare dallo stato della sessione ASP. Dalla tua pagina ASPX puoi fare una richiesta web alla tua pagina ASP e restituire qualsiasi informazione di sessione nell'header, querystring, o anche fare un scrap del carico del restulante. In alternativa puoi restituire un flusso XML e creare un servizio web di un uomo povero.

Inoltre, è possibile ottenere lo stato della sessione da ASP.NET facendo il contrario e creando una pagina .NET che acceda alle informazioni sulla sessione e la restituisca.

Non è una buona idea e piena di problemi di sicurezza. L'ho visto fare è tutto ciò che sto dicendo. Probabilmente è meglio fare affidamento sul database e possibilmente passare l'ID della sessione.

Answer 6

Beh, ho appena affrontato questo problema e voglio dirti che sono stati in grado di risolverlo in un modo. La soluzione era relativamente facile e in realtà dipende dallo sviluppo originale, nel mio caso il flusso di sistema richiede di accedere in una pagina default.aspx e dopo aver convalidato l'utente/password sono corretti la pagina Init.asp viene eseguita e esattamente lì le vars di sessione vengono create e caricate (in realtà sono solo il minimo necessario) dopo che l'ultima istruzione reindirizza l'utente a mainmenu.aspx e forma quella pagina che chiamiamo file .aspx e .asp.

Questa soluzione ha funzionato per me proprio a causa delle elezioni che lo sviluppatore originale ha realizzato quando ha progettato questa applicazione ASP 3.0 e come potete immaginare non riesco a recuperare quei valori nelle pagine di asp.net.

Answer 7

Ho appena passato questo. La mia soluzione era di racchiudere tutto in un'app di nodejs. Distribuisco i token JWT da .NET Web API con tutte le attestazioni degli utenti codificate nel payload. Questo token viene memorizzato in un cookie sul client.Il cookie verrà automaticamente inviato su ogni richiesta al tuo dominio, quindi tutto ciò che devi fare è leggere il valore del cookie dall'intestazione e decodificare il carico utile (in ASP.NET e Classic ASP in modo indipendente). Una volta letto il contenuto, puoi semplicemente impostare le variabili di sessione in modo che corrispondano a quelle che erano incorporate nel token JWT.

Preferisco questo metodo perché è necessaria la sincronizzazione del database 0 e sposta la tua applicazione su OAuth2 openid e lontano dalla sessione.