Domanda

Ho un'applicazione Web che utilizza l'oggetto Messaggio CDO per inviare rapporti via e-mail.

Ad esempio:

Dim objCDO
Set objCDO = Server.CreateObject("CDO.Message")
objCDO.CreateMHTMLBody "http://server/report.asp"

Il problema è che quando invia una richiesta a IIS, non eredita l'identità della sessione ASP dell'utente che ha effettuato l'accesso, ovvero le variabili di sessione utilizzate per autenticare le richieste prima di consentire l'accesso al contenuto sono vuote. Questo rende difficile l'autenticazione, costringendomi ad aggiungere una variabile di querystring (perché come puoi vedere, non puoi aggiungere una variabile di modulo a questa richiesta) come:

objCDO.CreateMHTMLBody "http://server/report.asp?userid=xx&password=xx"

Sicuramente ci deve essere un modo di autorizzazione nel rapporto per verificare se la richiesta proviene dal computer locale, ovvero l'oggetto CDO nello script del mailer, annullando così la necessità di autenticazione?

È stato utile?

Soluzione

Solo non farlo! Per questi motivi: -

  • Effettuando una seconda richiesta nel server, il thread corrente si bloccherà, se ne hai troppi, bloccherai l'applicazione.
  • CreateHTMLBody utilizza internamente lo stack http WinINET per effettuare la richiesta. Questo stack è destinato all'uso in scenari interattivi client. Nello scenario del server non è thread-safe.
  • Perdi tutto il contesto della sessione in modo che (come stai scoprendo) possa rendere le cose più difficili o meno sicure. Inoltre, può creare un carico di sessioni indesiderate.

Mentre il suo vero CreateHTMLBody può essere molto conveniente, può anche creare e-mail gonfiate. Nella situazione del server devi davvero creare l'e-mail con il codice piuttosto che utilizzare questo metodo allettante.

Modifica

Sembra che Jimbo abbia in mente scenari più generali di quanto non sia CreateHTMLBody. Lo scenario generale è che un componente (su cui il consumatore non ha alcun controllo) viene utilizzato in una pagina ASP (designeremo questa la "Pagina cliente") e invia una richiesta successiva (potenzialmente tramite WinINET) a un'altra pagina ASP ( designeremo questa "Pagina di servizio"). Si presume che l'unica cosa la "Pagina cliente" può controllare l'utilizzo del componente è l'URL fornito ad esso.

Ecco alcuni approcci per evitare o mitigare i problemi descritti sopra.

Gestione dei problemi di blocco: Posizionamento della "Pagina cliente" e la "Pagina del servizio" in diverse applicazioni ASP eviterebbe i problemi di blocco. Il mio suggerimento sarebbe di inserire la "Pagina cliente" in un'altra applicazione rispetto al resto dell'applicazione e che questa nuova applicazione si troverebbe nella sottocartella dell'applicazione principale.

Gestione dei problemi con WinINET: colloca la nuova applicazione nel suo pool di applicazioni. Se l'utilizzo di WinINET in un modo non sicuro causa un problema, non influisce sul processo dell'applicazione principale. In effetti, metterlo nel proprio processo può aiutare a evitare tali problemi. (Nessuna garanzia qui, ma è il massimo che puoi ottenere per evitare completamente i problemi di WinINET).

Controllo della sicurezza: configura la pagina di servizio " " per accettare richieste solo dalla "Pagina Cliente". Esistono probabilmente diversi modi per farlo, ma il più semplice è abilitare la sicurezza basata su IP, le richieste alla "Pagina del servizio" dovrebbe provenire solo da un IP specifico o almeno da un insieme limitato di indirizzi IP.

Gestione autenticazione: durante l'accesso all'applicazione principale creare un cookie volatile contenente un valore univoco. Poiché la "Pagina cliente" viene percepito come una sottocartella dell'applicazione principale dal browser che riceverà questo cookie. La "Pagina cliente" può utilizzare questo cookie per confermare l'autenticità della richiesta e / o passarlo nell'URL quando si utilizza il componente.

Soppressione della creazione di sessioni prolifiche: disporre della pagina di servizio " " chiama Session.Abandon prima di completare l'operazione.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top