ASP.NET [Italiano]

Scott Guthrie a Roma ... che silenzio!

Raffaele Rialdi — Tue, 08 Feb 2005 09:55:00 GMT

Ma insomma, tanto rumore per Scott Guthrie, il papà di asp.net, a Roma. Si dice evento unico, tutti che corrono a vederlo (io proprio non potevo esserci) e alla fine ... silenzio totale sui blog, sul msn, sui vari web.

Delusione o pubblico esigente? Devo cominciare a preoccuparmi per il nostro evento del 10 Febbraio?

XmlHttp e le applicazioni server

Raffaele Rialdi — Tue, 14 Dec 2004 14:03:00 GMT

In riferimento alla giusta raccomandazione di Fabio che fa seguito al mio post su XmlHttp, mi preme aggiungere un concetto che avevo già ribadito a Luglio 2003 nel newsgroup microsoft.public.it.dotnet.asp.

XmlHttp è lo strumento giusto se lo si usa sul client ma attenzione a non usarlo dentro una applicazione server come asp.net. Questa limitazione è dovuta al fatto che usa la libreria Wininet che tra le altre cose limita le connessioni contemporanee.

Questo è il motivo per cui esiste ServerXmlHttp che è un ottimo sistema per dialogare tra un'applicazione asp ed una asp.net.

Finalmente XmlHttp prenderà piede

Raffaele Rialdi — Tue, 14 Dec 2004 10:19:00 GMT

Come ho visto il post di Andrea sono subito andato a vedere il sorgente dello script di Google Suggest e con piacere ho visto confermare la mia ipotesi, cioè l'uso del componente XmlHttp.

È dai tempi di asp che mi dilettavo a eseguire il binding con la <table> sul lato client e prelevare/aggiornare recordset disconnessi dal server via XmlHttp. Correvano gli anni in cui continuavo a tenere in aula il mitico corso 1017A (Mastering Web Application Development using Visual Interdev) opportunamente modificato (chi lo conosce sa di cosa parlo) ed uno dei sample che avevo sviluppato ad-hoc usava proprio XmlHttp per evitare il refresh del browser.

Poi un giorno vedo la beta 1 del framework 1.0 e guardando asp.net mi dico: “userà sicuramente XmlHttp per i postback“ ... e invece no, con grande delusione.

Il tempo passa e sui forum di UGIdotNET e sui newsgroup ho continuato ad istigare tanti ad usarlo e qualcuno mi ha pure dato retta.

Poi un giorno alla PDC 2003, un certo Nikhil Kothari annuncia che in Asp.net 2.0 alcuni nuovi server controls (direi che lui se ne capisce ;-)) usano XmlHttp per il meccanismo di postback.

Finalmente arriva il momento della diffusione e ora che Google userà questo componente, non ci sarà più browser che non lo possa supportare.

Che sollievo!

Color injection?

Raffaele Rialdi — Mon, 13 Dec 2004 10:04:00 GMT

Io e Andrea abbiamo appena ricevuto una mail da Dino e personalmente la stavo per prendere come una divertente sfottitura al giustificato panico da injection che si sta diffondendo.

Invece è una cosa serissima e invito tutti a leggere il suo post.

Asp.net canonicalization bug: non fidatevi ciecamente della fix

Raffaele Rialdi — Tue, 12 Oct 2004 13:30:00 GMT

È capitato, e quindi è un precedente a cui stare molto attenti. La patch si installa solo se trova asp.net installato... e fin qui sembra una cosa corretta.

Il problema è che asp.net può funzionare anche se apparentemente non è installato.... come? Asp.net è 'ufficialmente' installato quando è impostata la chiave di registry:
HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v1.1.4322\Install = 1

Quindi accade che asp.net ci sia, funzioni, il comando “aspnet_regiis -lv” dice che tutto è ok, ma la chiave di registry dice che asp.net non c'è.

Quando capita questa strana cosa (a dire il vero è una cosa rara anche se non saprei dire quanto) il machine.config non viene patchato e quindi si resta vulnerabili.
Il rimedio è presto fatto: controllare che in tutti i machine.config delle versioni di framework installate sul pc, al tag <httpModules ... /> ci sia questa riga:
<add name="ValidatePathModule" type="Microsoft.Web.ValidatePathModule, Microsoft.Web.ValidatePathModule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=eba19824f86fdadd"/>

Asp.net canonicalization bug: nuovo articolo di KB

Raffaele Rialdi — Fri, 08 Oct 2004 09:45:00 GMT

Come già anticipato da Lorenzo qui, è disponibile la patch (cioè un HttpModule) che risolve il bug per tutti siti asp.net su un server.

In questo nuovo articolo viene spiegato come funziona il nuovo Microsoft.Web.ValidatePathModule installato nel machine.config ed altre importanti informazioni sull'installazione/disinstallazione.

Il bug c'è ma non è della Forms Authentication

Raffaele Rialdi — Sat, 02 Oct 2004 19:32:00 GMT

Quando ho letto il link che Lorenzo e poi Andrea mi hanno mandato riguardante il bug della forms authentication, mi è venuto subito l'atroce sospetto e dopo un veloce test ho avuto la conferma.

Il bug riguarda le autorizzazioni di asp.net indipendentemente dal tipo di autenticazione usata.

Si, avete capito bene, con lo stesso exploit ho potuto bucare un progetto di test interamente protetto con la Windows Authentication.

Ovviamente non si tratta di un bug di Kerberos o di Windows. L'autenticazione Windows deve avere luogo altrimenti l'utente non può fare nulla.
Io mi sono loggato alla home page della web app di test come semplice user. Quindi ho protetto una pagina in modo che solo gli administrators potessero raggiungerla.
Nella home page del progetto ho creato due link alla pagina protetta: un link 'normale' ed uno con il %5C. Il risultato è stato quello aspettato e con il secondo link sono riuscito ad entrare nella pagina di admin anche se ero loggato come semplice utente.

Il bug sembra proprio girare intorno al modulo di autorizzazione, non ho potuto ancora identificare di preciso il punto, visto che sono lontano dalla mia postazione operativa.
Al mio rientro non esiterò a scomodare i sorgenti del framework per identificare meglio il problema.

Redirigere l'utente su una pagina alla scadenza della Session

Raffaele Rialdi — Wed, 22 Sep 2004 17:03:00 GMT

Ho raccolto recentemente una domanda su come si potesse redirezionare su una certa pagina l'utente a cui sia scaduta la sessione.
Effettivamente alcune volte nella Session_Start non sempre si hanno a disposizione tutte le informazioni per poter ricostruire i dati di una Session ormai scaduta. Soluzioni alternative certamente ci sono ma volendo scegliere questa strada, ecco una possibile soluzione.

L'evento PreRequestHandlerExecute viene eseguito prima di ogni richiesta di pagina ed ha in più il privilegio di poter accedere alla Session.
Se un valore arbitrario della session non è presente, significa che la session è nuova e quindi devo redirigere l'utente sulla pagina prestabilita (Webform1.aspx nell'esempio).

Nel global.asax.cs:

protected void Application_PreRequestHandlerExecute(Object sender, EventArgs e)
{
   string Uri = HttpContext.Current.Request.Url.AbsoluteUri.ToLower();
   if(Uri.EndsWith("WebForm1.aspx".ToLower()))
      return;
   if(Session["test"] == null)
      Response.Redirect("~/Webform1.aspx");
}

I più critici si domanderanno perchè il ToLower() sulla stringa literal. Il motivo è solo un promemoria per chi dovesse metterci una stringa, una funzione o quant'altro. Occhio insomma a non dimenticarsi di confrontare le stringhe con lo stesso 'case'.
Ovviamente nella webform1.aspx.cs è poi necessario inizializzare quel valore in modo arbitrario:

Session["test"] == “1”;

Banale, quasi scontato, ma a volte utile ...

[ASP.NET] Un custom control per dare il focus lato client

Raffaele Rialdi — Tue, 21 Sep 2004 19:35:00 GMT

Avete presente quando caricate la pagina di google quanto sia comodo avere subito il focus sulla textbox di ricerca?
Lo script da usare è estremamente semplice:

dove IdControlloLatoClient è l'id del controllo a cui dare il focus, tassativamente ottenuto con la proprietà ClientID.
Lo script va poi registrato con il metodo RegisterStartupScript.

Per risolvere la questione in modo più elegante ho buttato giù un piccolo custom control che registra questo script.

[DefaultProperty("FocusControl"), ToolboxData("<{0}:FirstFocus runat=server>")]
public class FirstFocus : Control
{
   private string StartScript = "\r\n ";
   protected Control FindNestedControl(Control root, string name)
   {
      foreach(Control ctl in root.Controls)
      {
      if(ctl.ID == name)
         return ctl;
      if(ctl.HasControls())
         return FindNestedControl(ctl, name);
      }
      return null;
   }

   protected string GetControlRenderID(string name)
   {
      //Control ctl = FindControl(name);
      Control ctl = FindNestedControl(Page, name);
      if (ctl == null)
         return "";
      return ctl.ClientID;
   }

   protected override void OnPreRender(EventArgs e)
   {
      if(FocusControl == string.Empty)
         return;
      string CID = GetControlRenderID(FocusControl);
      if(CID != string.Empty)
         Page.RegisterStartupScript(ClientID, StartScript + "document.all['" + CID + "'].focus();" + EndScript);
   }

   ///

   /// Il control ID da specificare nel caso degli UserControl è quello dello UserControl
   /// Poi è necessario che lo UserControl faccia l'override della proprietà ClientID
   /// e restituisca al posto del proprio quello del controllo che si vuole guadagni il focus
   ///

   [Category("Behaviour"),
   DefaultValue(""),
   Description("Control you wish will gain control at load time"),
   TypeConverter(typeof(AllPageControlsConverter))]
   public string FocusControl
   {
      get
      {
         string ctl = ViewState["FocusControl"] as string;
         return (ctl == null) ? string.Empty : ctl;
      }
      set
      {
         ViewState["FocusControl"] = value;
      }
   }
}

Per rendere più gradevole l'uso del controllo ho poi costruito un UITypeConverter per scegliere a design time, con una combo nella property toolbox, il controllo a cui dare il focus.

public class AllPageControlsConverter : StringConverter
{
   private object[] GetControls(ITypeDescriptorContext context)
   {
      IContainer container = context.Container;
      ComponentCollection coll = container.Components;
      ArrayList list = new ArrayList();
      foreach (IComponent comp in coll)
      {
         if (!(comp is Control))
            continue;

         Control ctl = (Control) comp;
         if ((ctl.ID != null) && (ctl.ID.Length != 0) && (ctl.ID != (((Control)context.Instance)).ID))
         {
            list.Add(string.Copy(ctl.ID));
         }
      }
      list.Sort(Comparer.Default);
      return list.ToArray();
   }

   public override TypeConverter.StandardValuesCollection GetStandardValues(ITypeDescriptorContext context)
   {
      if (context == null || context.Container == null)
         return null;
      object[] ctls = GetControls(context);
      if (ctls != null)
         return new TypeConverter.StandardValuesCollection(ctls);
      return null;
   }

   public override bool GetStandardValuesExclusive(ITypeDescriptorContext context)
   {
      return false;
   }
   public override bool GetStandardValuesSupported(ITypeDescriptorContext context)
   {
      return true;
   }
}

Infine un ultimo particolare: e se il controllo a cui dare il focus è contenuto all'interno di uno UserControl? La risposta è semplice, basta fare l'override nello user control della proprietà ClientID e restituire quello del controllo 'principale'. In questo modo, indicando lo user control come destinatario del focus, verrà letto il ClientID del controllo contenuto nello User Control.

/// proprietà ClientID dello User Control
public override string ClientID
{
   get
   {
      return txtUsername.ClientID;   // txtUsername è il controllo contenuto nello User COntrol a cui si vuole dare il focus
   }
}

Ci sono sicuramente degli spunti di miglioramento, come il piccolo spreco nel viewstate per conservare il nome del controllo. Ma a me è bastato così ...