Emula ASP.NET cookie di autenticazione

Question

ho mantenere un sito web ASP.NET MVC che utilizza

FormsAuthentication.SetAuthCookie(userName, createPersistentCookie); 

di firmare gli utenti (che finiscono con un cookie di nome .ASPXAUTH).

Il client desidera che aggiunga una funzione HTML a PDF, quindi impacchetta la libreria wkhtmltopdf e la chiama. Questo finisce per essere un comando che è simile al seguente:

wkhtmltopdf http://example.com/Foo/Edit/42 Foo.pdf 

Tuttavia, che si traduce in fare un PDF della schermata di accesso, come il programma utente viene reindirizzato wkhtmltopdf in quanto non ha il cookie corretto.

va bene dal momento che, in base alla documentazione wkhtmltopdf, c'è un argomento come questo:

--cookie <name> <value>   Set an additional cookie (repeatable) 

Così ho modificare il comando di essere:

wkhtmltopdf --cookie .ASPXAUTH 91C0DE4C... http://example.com/Foo/Edit/42 Foo.pdf 

Qualora il valore del cookie viene recuperato utilizzando Request.Cookie[".ASPXAUTH"].Value .

Sfortunatamente, questo non sembra funzionare e non ho idea del perché. So che ASP.NET sta ricevendo il cookie perché quando interrompo la pagina di accesso dopo il reindirizzamento, posso vedere che è stato impostato. Quindi perché ASP.NET non accetta il mio cookie copiato?

Ecco il contenuto di una richiesta che ASP.NET consente (da Chrome):

GET http://localhost:50189/ReportingMonth/Edit/1193391 HTTP/1.1 
Host: localhost:50189 
Connection: keep-alive 
Cache-Control: max-age=0 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.163 Safari/535.1 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Encoding: gzip,deflate,sdch 
Accept-Language: en-CA,en;q=0.8,en-US;q=0.6 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 
Cookie: .ASPXAUTH=C8189041BF69FEF89A834B6F5035B786EC40145FFFBA3DBB6A04973BC58021C73D8D374E3577AA44BC26A784BC8A0C24831CF49FBD596BFFBA42C613E3C2C0C893D1587B7743D051643088BB8BAB667C047E0D1B84D7B76C4AADA7C62AB460D87C954BF9118BF5945E7D325D455CFD13A34C3DD5E597AFDF75D3C8EE76D8488B08ABBF6AE065B4C57CE47CB65AB17D65; language=en; ui-tabs-[object Object]=0 

Ed ecco uno che reindirizza al login (da wkhtmltopdf):

GET http://localhost:50189/ReportingMonth/Edit/1193391 HTTP/1.1 
Cookie: .ASPXAUTH=C8189041BF69FEF89A834B6F5035B786EC40145FFFBA3DBB6A04973BC58021C73D8D374E3577AA44BC26A784BC8A0C24831CF49FBD596BFFBA42C613E3C2C0C893D1587B7743D051643088BB8BAB667C047E0D1B84D7B76C4AADA7C62AB460D87C954BF9118BF5945E7D325D455CFD13A34C3DD5E597AFDF75D3C8EE76D8488B08ABBF6AE065B4C57CE47CB65AB17D65 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.1 Safari/533.3 
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 
Connection: Keep-Alive 
Accept-Encoding: gzip 
Accept-Language: en-US,* 
Host: localhost:50189 

Answer 1

Ho trovato il problema. Ho notato che una volta modificato il campo User-Agent (in Fiddler) per essere uguale a Chrome, funzionava correttamente. Così ho fatto un po 'di investigazione sul web e ho scoperto this bug on the wkhtmltopdf project page.

Dal bug:

Questo è un problema in ASP .NET 4.0 come sembra che .NET interpreta la stringa User-Agent "Mozilla/5.0 (Windows; U; Windows NT 6.1; en -AU) AppleWebKit/532.4 (KHTML, come Gecko) Qt/4.6.1 Safari/532.4 "come non cookies di supporto che penso impedisca l'opzione --cookie di lavorare sotto ASP.

Quindi sembra che la soluzione è o trovare un modo per rendere wkhtmltopdf cambiare è User-Agent intestazione (non guardando promettente) o di capire un modo per dire che ASP.NET che l'agente utente fa cookie di supporto.

Grazie per il tuo aiuto Darin Dimitrov.

Aggiornamento

Ok, ho capito come dire ASP.NET che il browser Web Qt utilizzato da wkhtmltopdf supporta i cookie. È necessario creare un file denominato qt.browser e salvarlo in una directory callde App_Browsers nella radice del progetto ASP.NET. Ecco ciò che si mette nel file qt.browser:

<browsers> 
    <!-- Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.1 (KHTML, like Gecko) Qt/4.7.1 Safari/530.1 --> 
    <browser id="Qt" parentID="Safari"> 
     <identification> 
      <userAgent match="Qt/(?'version'(?'major'\d+)(\.(?'minor'\d+)?)\w*)" /> 
     </identification>  

     <capabilities> 
      <capability name="browser"       value="Qt" /> 
      <capability name="version"       value="${version}" /> 
      <capability name="majorversion"     value="${major}" /> 
      <capability name="minorversion"     value="${minor}" /> 
      <capability name="type"       value="Qt${major}" /> 
      <capability name="ecmascriptversion"    value="3.0" /> 
      <capability name="javascript"      value="true" /> 
      <capability name="javascriptversion"    value="1.7" /> 
      <capability name="w3cdomversion"     value="1.0" /> 
      <capability name="tagwriter"      value="System.Web.UI.HtmlTextWriter" /> 
      <capability name="cookies"       value="true" /> 
      <capability name="frames"       value="true" /> 
      <capability name="javaapplets"      value="true" /> 
      <capability name="supportsAccesskeyAttribute"  value="true" /> 
      <capability name="supportsCallback"    value="true" /> 
      <capability name="supportsDivNoWrap"    value="false" /> 
      <capability name="supportsFileUpload"    value="true" /> 
      <capability name="supportsMaintainScrollPositionOnPostback" value="true" /> 
      <capability name="supportsMultilineTextBoxDisplay" value="true" /> 
      <capability name="supportsXmlHttp"     value="true" /> 
      <capability name="tables"       value="true" /> 
     </capabilities> 
    </browser> 
</browsers> 

Poi ri-compilare il progetto (e forse riavviare il server se potete) e poi presto, è possibile emulare il cookie di autenticazione ASP.NET!

Answer 2

Sembra like a bug e sembra esserci un fix in the trunk.