Tutorials

Scrivere un control class converter per VB6(2)XAML

Davide Senatore — Wed, 29 Nov 2006 15:05:00 GMT

Per tutti coloro i quali sono interessati all'utilizzo ed alla personalizzazione del tools VB6(2)XAML, pubblico un esempio di come possa essere possibile ridefinire il rendering dell'elemento VB.Label con una classe proprietaria. Dopo aver creato un progetto di tipo ClassLibrary, possiamo aggiungere la referenza a VB62XAML.exe nella quale si trova la classe VBControl, dalla quale dovremo ereditare.

Implementando un override del metodo RenderToWPF possiamo definire come renderizzare il nostro controllo Label. Nell'esempio che ho riportato sotto, è possibile osservare una tecnica basata sulla creazione "manuale" degli elementi, ed un'altra basata sull'utilizzo di templates che magari possono essere caricati da disco.

Imports System.Xml
Imports CodeSapiens.VB62XAML

Public Class MyLabel
    Inherits CodeSapiens.VB62XAML.VBControl

    ''' <summary>
    ''' Override base function RenderToWPF and replace with new rendering attributes
    ''' </summary>
    ''' <param name="document">The XML document that parser passes to classes</param>
    ''' <returns>XMLElement representing the control in XML Format</returns>
    ''' <remarks></remarks>
    Public Overrides Function RenderToWPF(ByVal document As System.Xml.XmlDocument) As System.Xml.XmlElement
        'Create element
        Dim _item As XmlElement = document.CreateElement("Label")
        'Set base positioning attributes
        _item.SetAttribute("Name", Helpers.BuildName(Me.Name, Me.Properties))
        _item.SetAttribute("Canvas.Left", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Left").Value)))
        _item.SetAttribute("Canvas.Top", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Top").Value)))
        _item.SetAttribute("Width", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Width").Value)))
        _item.SetAttribute("Height", Helpers.TwipsToPixels(Convert.ToInt32(Me.Properties.GetProperty("Height").Value)))

        _item.SetAttribute("Content", Me.Properties.GetProperty("Caption").Value)
        _item.SetAttribute("Padding", "0,0,0,0")

        'Create a document fragment to show another manner of embedding XML in Control Rendering
        Dim _docFrag As XmlDocumentFragment = document.CreateDocumentFragment()

        Dim _gradientTemplate As String = String.Empty
        ' This string could be loaded from disk, and maybe values could be placeholders
        ' so we can substitute them at run-time using our special values...
        _gradientTemplate = "<Label.Background>" & _
                            "    <LinearGradientBrush StartPoint=""0.5,0"" EndPoint=""0.5,1"">" & _
                            "       <GradientStop Offset=""0.0"" Color=""LightBlue""/>" & _
                            "       <GradientStop Offset=""1.0"" Color=""SlateBlue""/>" & _
                            "   </LinearGradientBrush>" & _
                            "</Label.Background>"

        _docFrag.InnerXml = _gradientTemplate
        _item.AppendChild(_docFrag)

        'Handle font generation
        If Me.Properties.ContainsProperty("Font") Then
            Me.RenderFont(Me.Properties.GetProperty("Font"), _item)
        End If

        Return _item
    End Function

End Class

Uno dei punti fondamentali, comunque, è rappresentato dalla "dichiarazione" fatta nel file .config dell'applicazione, del class converter che utilizzerà il controllo Label:

<add key="VB.Label" value="CustomControls, CustomControls.MyLabel"/>

Articolo su WSE 3.0 e ASP.net Membership API

Davide Senatore — Tue, 10 Oct 2006 09:00:00 GMT

Con mio grande piacere, oggi è stato pubblicato il mio ultimo articolo sul sito di XeDotNet. Nell'articolo in questione si parla di autenticazione ed autorizzazione tramite WSE 3.0 e Membership API. Grazie all'approccio trattato si può realizzare un sistema Single Sign On tra Web Services ed applicazioni ASP.net, condividendo l'identità dell'utente tra le varie applicazioni. Lo potete trovare qui.

Single Sign-On con ASP.net 2.0 e Membership API

Davide Senatore — Wed, 07 Jun 2006 15:15:00 GMT

Spesso mi è capitato di imbattermi nel problema di avere più applicazioni web che permettano agli stessi utenti di autenticarsi e di lavorare liberamente al loro interno. Ancora più spesso mi sono imbattuto nella difficoltà di realizzare tale obiettivo, soprattutto per via del fatto che ogni applicazione web implementava l'autenticazione a modo suo, con risultati spesso discutibili dal punto di vista della sicurezza.

Molte volte ci siamo trovati a valutare come sistema di Single Sign-On l'autenticazione su Active Directory, ma questa è fattibile soprattutto in ambienti intranet e non in un ambiente internet, dove magari i nostri utenti possono addirittura auto-registrarsi.

L'eleganza della Membership API permette di sorpassare ogni problema, raggiungendo l'obiettivo di condividere le credenziali dell'utente attraverso più applicazioni web. Ovvero si potrà, ad esempio, creare un'applicazione web dedicata alle vendite e, successivamente, un'applicazione web dedicata alla reportistica. Queste due applicazioni potranno condividere le informazioni relative agli utenti ed ai loro ruoli, in modo da uniformare la gestione della sicurezza.

Ora, come implementare una feature così appetibile? Beh, vi assicuro che è più facile farlo che spiegarlo ...

Come prima cosa, dobbiamo evitare di usare il "classico" database SQL express che il buon vecchi VS2005 crea automaticamente per noi. Piuttosto, creiamo un database che fungerà da repository condiviso di credenziali (Shared Credential Repository, SCR), mediante il tool aspnet_regsql.exe, che possiamo trovare nella directory %WINDOWS%\Microsoft.NET\Framework\v2.0.50727. Lasciando come <default> la selezione del database, creeremo un DB di nome ASPNETDB nel nostro server SQL che potrà essere utilizzato per i nostri fini. A questo punto, visto che siamo nei paraggi, diamo un'occhiatina al file Machine.config che si trova nella sottodirectory CONFIG. Al suo interno possiamo trovare le seguenti parti "interessanti":

<connectionStrings>
    <add name="LocalSqlServer"
    connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" />
</connectionStrings>
...snip...
<membership>
    <providers>
        <add name="AspNetSqlMembershipProvider"
        type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral,
        PublicKeyToken=b03f5f7f11d50a3a"
        connectionStringName="LocalSqlServer"
        enablePasswordRetrieval="false"
        enablePasswordReset="true"
        requiresQuestionAndAnswer="true"
        applicationName="/"
        requiresUniqueEmail="false"
        passwordFormat="Hashed"
        maxInvalidPasswordAttempts="5"
        minRequiredPasswordLength="7"
        minRequiredNonalphanumericCharacters="1"
        passwordAttemptWindow="10"
        passwordStrengthRegularExpression="" />
    </providers>
</membership>
...snip...

Il punto su cui ragionare, in vista delle nostre applicazioni, è la ConnectionString "LocalSqlServer" e come questa viene utilizzata dal provider AspNetSqlMembershipProvider. Noi vogliamo mantenere questo provider senza apportare modifiche in ciascuna applicazione web, in modo che modificando il comportamento della membership all'interno del Machine.config, tutte le applicazioni installate sul nostro server beneficino del comportamento. Del resto è anche una questione di coerenza nelle policies di sicurezza, giusto? Preso atto di questo, creiamo una applicazione web di nome SalesApp, aggiungiamo un paio di pagine Login.aspx e Register.aspx nelle quali aggiungiamo, rispettivamente, un controllo Login ed un controllo User Creation Wizard. Nella pagina Default.aspx aggiungiamo un controllo LoginStatus e un controllo LoginName. Il pezzo forte di tutto questo, comunque è il file Web.config, che deve essere così composto:

<?xml version="1.0"?>
<configuration>
  <appSettings/>
  <connectionStrings>
    <clear/>
    
    <add name="LocalSqlServer" connectionString="SERVER=MYSERVER;DATABASE=ASPNETDB;UID=sa;PWD=password" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <system.web>
    <compilation debug="false" strict="false" explicit="true" />
    <authentication mode="Forms">
      
      <forms name=".SHAREDTOKEN" loginUrl="login.aspx" protection="All"
              timeout="30"
              path="/"
              requireSSL="false"
              slidingExpiration="true"
              cookieless="UseCookies"/>
    </authentication>
    
    <machineKey validationKey="95E209A1882F59B1585FD2691BB0AEF28E8158C1CD26EADA9B2B3CF8821F2D3D39347B487F72D94E438E4EE510A730FE979A3E79D18A5DB453FE87979D25AACC" decryptionKey="B753AE2B2CEAFD2BA6B938744ECD8550ECE5F6BB51506E43" validation="SHA1" />
    
    <authorization>
      <deny users="?" />
    </authorization>
  </system.web>
</configuration>

Esaminiamo, dunque, questo file, fondamentale per il buon funzionamento della nostra "Shared-Membership"; ho modificato la stringa di connessione LocalSqlServer, in modo da farla puntare allo Shared Credential Repository creato in precedenza. Nell'elemento authentication si può vedere l'attibuto mode, impostato a Forms, ed all'interno, l'elemento forms configurato con un name, un path ed una protection ben definite. Dobbiamo fare attenzione a questi valori, perchè dovranno essere uguali in ogni applicazione che vogliamo far entrare nella nostra Shared Membership (nel club, per intenderci...). Oltre a questa impostazione, un altro elemento deve essere identico in tutte le nostre web application, ed è l'elemento machineKey. I tre attributi validationKey, decryptionKey e validation devono essere identici sempre per tutte le web app del club. Per generare valori validi riferitevi a MachineKey Generator.

A questo punto, il gioco è fatto! Per creare il primo utente, rimuovete il deny users="?" in modo da poter navigare la pagina register.aspx e create l'utente. Questo verrà creato all'interno del repository condiviso, e sarà a disposizione di tutte le applicazioni che utilizzeranno questo pattern di autenticazione condivisa. Ripristinando il deny users, la cosa simpatica è che se create un'applicazione di nome ReportApp, copiate il file web.config dalla SalesApp alla ReportApp, create un link che dalla SalesApp punti alla ReportApp e vi autenticate nella SalesApp, una volta giunti alla ReportApp, questa vi "riconoscerà" e nella pagina di default comparirà il nome del vostro utente. Stiamo quindi lavorando con un utente in un'applicazione web, essendoci autenticati presso un'altra applicazione. Estremizzando, potremmo creare un'applicazione per l'autenticazione che rinvia ad altre applicazioni concrete che implementino le funzionalità desiderate. A questo indirizzo potete trovare un semplice progetto con due applicazioni web per testare questa feature estremamente potente di ASP.net 2.0.

Nel caso in cui vogliate riportare le impostazioni del provider nel Web.Config, fate attenzione al nome dell'applicazione! Se volete condividere Membership Ruoli e Profili tra le applicazioni, dovete impostare l'attributo name allo stesso valore per ogni applicazione!

Happy authenticating!