Archivi tag: Csharp

Estendere il WebClient per gestire un CookieStore

In C# , le system.net mettono a disposizione un oggetto chiamato WebClient per fare delle chiamate http in post a risorse identificate da un URI.

Nel mio caso l’ho utilizzato per fare delle chiamate dal CodeBehind di un applicazione web, per interrogare dei servizi web esposti in maniera restfull che accettavano dati in POST.

Dovendo gestire la sessione con questi servizi di backend e a volte avendo la necessità di dovergli pasare dei Cookie di autenticazione o altri cookie , mi sono trovato a doverlo estendere (per non lavorare direttamente con il WebRequest, oggetto su cui poggia il WebClient).

Il webclient offre pochissime funzionalità, ma estenderlo è molto facile.

In questo esempio aggiungiamo la possibilità di creare un proprio CookieStore, prima di una chiamata, in modo da potergli passare tutti i cookie (presi ad esempio dalla Request arrivata alla nostra pagina aspx) necessari al servizio che risponde all’URI interrogata.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
using System;

using System.Net;

using System.Web;

public class ExtendedWebClient : WebClient

{

    private CookieContainer m_container = new CookieContainer();

    protected override WebRequest GetWebRequest(Uri address)

    {

        WebRequest request = base.GetWebRequest(address);
        HttpWebRequest webRequest = request as HttpWebRequest;
        if (webRequest!=null){
            webRequest.CookieContainer = m_container;
        }
        return request;
    }

    public void SetCookies(HttpCookieCollection collection,string domain){
        m_container = new CookieStore();
        for (int j=0;j<collection.Count;j++){
            HttpCookie httpCookie = collection.Get(j);
            Cookie cookie = new Cookie();
            cookie.Domain = domain;
            cookie.Expires = httpCookie.Expires;  
            cookie.Name = httpCookie.Name;
            cookie.Path = httpCookie.Path;
            cookie.Secure = httpCookie.Secure;
            cookie.Value = httpCookie.Value;
            m_container.Add(cookie);
        }
    }
}

Oltre a gestire il cookieStore, dobbiamo preoccuparci della conversione dei cookies da HttpCookie (arrivati dalla Request) a quelli più dettagliati della System.Net.

Per utilizzare il nostro nuovo webclient e passargli i cookie possiamo fare in questo modo:

1
2
3
4
5
    ExtendendWebClient client = new ExtendedWebClient();
    client.SetCookies(request.Cookies,request.Url.Host);
    byte[] data = client.DownloadData("http://www.google.it");
    System.Text.Encoding enc = System.Text.Encoding.UTF8;
    string output = enc.GetString(data);

In questo modo tutti i cookie vengono impostati nel webclient prima di eseguire la webRequest.

Giocando con il parametro Domain, possiamo andare a filtrare i cookie che ci interessano per la chiamata in questione.

Problemi di deserializzazione array in c#

Un caso semplicissimo,può diventare un incubo per diverse ore…

Un xml di questo tipo:

1
2
3
4
5
6
7
8
9
10
11
<?xml version="1.0" encoding="utf-8"?>
<Applicazioni>
<Applicazione>
<NomeApplicazione>XXX1</NomeApplicazione>
<Stato>Attiva</Stato>
</Applicazione>
<Applicazione>
<NomeApplicazione>XXX2</NomeApplicazione>
<Stato>Attiva</Stato>
</Applicazione>
</Applicazioni>

L’utilizzo di una classe per deserializzare il contenuto di questo xml in un oggetto, in c# , diventa difficile a causa della natura del Root Item di questo xml, “Applicazioni”, che risulta essere un Array di “Applicazione” .

Per poter lavorare in maniera corretta con gli attributi XmlArray e XmlArrayItem, senza stare a romperci la testa, aggiungiamo un nodo contenitore ad “Applicazioni”, come nell’esempio seguente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?xml version="1.0" encoding="utf-8"?>

<ServizioStato>
<Applicazioni>
<Applicazione>
<NomeApplicazione>XXX1</NomeApplicazione>
<Stato>Attiva</Stato>
</Applicazione>
<Applicazione>
<NomeApplicazione>XXX2</NomeApplicazione>
<Stato>Attiva</Stato>
</Applicazione>
</Applicazioni>

</ServizioStato>

In questo modo possiamo andare a definire un oggetto per la deserializzazione cosi definito :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
using System;
using System.Xml.Serialization;

namespace ServizioStato
{

[Serializable()]
[XmlRoot("ServizioStato",Namespace="",IsNullable=false)]
public class ServizioStatoApplicazioni
{
private Applicazione[] applicazioni;

[XmlArray("Applicazioni")]
[XmlArrayItem("Applicazione", typeof(Applicazione))]
public Applicazione[] StatoApplicazioni
{
get { return this.applicazioni; }
set { this.applicazioni = value; }
}

}

[Serializable]
public class Applicazione
{
private string nomeApplicazioneField;
private string statoField;

[System.Xml.Serialization.XmlElementAttribute("Applicazione", Namespace="",Form = System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string Applicazione
{
get { return this.nomeApplicazioneField; }
set { this.nomeApplicazioneField = value; }
}
[System.Xml.Serialization.XmlElementAttribute("Stato", Namespace="",Form = System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string Stato
{
get { return this.statoField; }
set { this.statoField = value; }
}
}

Una cosa su cui riflettere è che il tool XSD per la generazione degli oggetti, non ci viene in aiuto con delle strutture definite come il primo esempio (prima dell’aggiunta del nodo ServizioStato), non riuscendo a generare le classi in maniera corretta.

 

Comprimere il contenuto di una risposta web, e analisi dell’Accept-Encoding

Il seguente articolo, è inerente c# e in particolare all’integrazione di un CompressionFilter nel  workflow di una chiamata web mediante il framework MVC2 di Microsoft, ma è applicabile in linea di massima a tutti i linguaggi. Si tratta fondamentalmente di applicare un algoritmo di compressione ai dati in output da una chiamata http, in modo da far viaggiare meno dati sulla rete, e accertarsi di quale metodi di compressione il client chiamante supporti.

Ci sono diversi tutorial sulla rete riguardo a questa problematica, ma è difficile trovare una risposta assoluta in quanto il vero problema non è la creazione di una funzione per la compressione (già implementate nei vari framework), ma nella decodifica corretta dell’Header Accept-Encoding che ci aiuta a dedurre che cosa supporti il chiamante, evitando così di applicare meccanismi di compressione non graditi o non supportati.

Banalmente basterebbe controllare se nell’header in questione sia presente la stringa gzip o deflate ,ad indicare che il client supporta i due algoritmi di compressione standard, ma in realtà le specifiche W3C sull’encoding, prevedono un funzionamento molto piu complesso.

 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Questo tipo di Headers si basano su un concetto di preferenza e pesi..

Alcuni esempi di valori possibili:

  • il più banale “gzip” oppure solo “deflate” ad indicare l’algoritmo desiderato.
  • “gzip,deflate” ad indicare la sequenza delle preferenze,
  • “gzip;q=0,deflate” ad indicare che gzip non dovrebbe minimamente essere usato (ha un peso Q pari a zero)
  • “gzip;q=0.4,deflate;q=0.4,identity;q=0.2” ad indicare la ripartizione tra le preferenze..
  • identity sta a indicare che non va assolutamente usato un content-encoding.. se espresso senza q, il default sui parametri e’ q=1 e quindi avrebbe sempre la precedenda come in questo esempio: “gzip;q=0.5,deflate;q=0.5,identity”..
  • “*” sta invece a indicare qualsiasi encoding

Da quello che si evince e’ impossibile andare a cercare semplicemente se nella stringa sia presente gzip o deflate.. perche si rischia di incappare in errori (come da esempio con lo “*” o con identity dove q=1)

Sulla rete si trovano gia delle List per valori pesati oppure realizziamo noi direttamente una semplice classe che tokenizza la stringa usando la virgola come separatore e poi tokenizza ogni token utlizzando il “;” . Ovviamente in caso di “*” la scelta di default possiamo attribuirla noi ad esempio gzip. Il sort dei token e’ eseguito sulla base del valore di q, andando a mettere q=1 a tutti gli elementi con q non specificato.

Poi passiamo alla parte MVC e realizziamo un ActionAttributeFilter che utilizzeremo per annotare le Action nel nostro Controller , che saranno sottoposte a compressione.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
using System;

using System.Collections.Generic;

using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Collections.Specialized;
using System.IO.Compression;
using System.IO;

public class CompressionFilter : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{

HttpRequestBase request = filterContext.HttpContext.Request;
string acceptEncodingHeader = request.Headers["Accept-Encoding"];
if (acceptEncodingHeader == null) return;

HttpResponseBase response = filterContext.HttpContext.Response;

MyFantasticQList encodingPreference = new MyFantasticQList(acceptEncodingHeader);

encodingPreference.setDefaultPreference("gzip");

string preferred = encodingPreference.findPreferred();

switch(preferred.Name){

case "gzip":

Response.AppendHeader("Content-Encoding""gzip");

Response.Filter = new GZipStream(Response.Filter, CompressionMode.Compress);

break;

case "deflate":

Response.AppendHeader("Content-Encoding""deflate");

Response.Filter = new DeflateStream(Response.Filter,CompressionMode.Compress);

break;

default:

break;

}

}

Realizzato il nostro CompressFilterAttribute, nel nostro controller basta annotare le action che devono restituire contenuto compresso:

 

1
2
3
4
5
6
7
8
9
[HttpPost()]

[CompressionFilter]

public ActionResult ListaElementi(string key){

//codice dell'action

}

In automatico prima della response, verrà applicato il content encoding corretto .

Ciao.