Oggi, lavorando sull'installazione di un portale DNN 4.0.1, mi sono scontrato con un problema abbastanza grosso e potenzialmente pericoloso della Membership/RoleProvider/ProfileProvider API di ASP.net 2.0.
Nel dettaglio, ho scoperto che, installando tutte le tabelle necessarie ad ASP.net con un utente che non fa parte del ruolo db_owner (dbo) di SQL 2000, DNN non funziona. Ma la doccia è stata ancora più fredda quando ho scoperto che il problema non era dovuto a delle chiamate tra stored procedures, bensì all' hard-coding dell'utente dbo all'interno dell'assembly System.Web.dll. Le varie chiamate alle stored procedures sono infatti del tipo
Dim _command1 as new SqlCommand("dbo.aspnet_CheckSchemaVersion",_cnn)
Il mio pensiero...
Ultimamente sto lavorando su un progetto che mi ha portato ad utilizzare un'architettura SOA che si basa su WSE per mettere in sicurezza le comunicazioni. Utilizzo dataset per lo scambio dei dati tra tier, e così facendo mi sono accorto di uno strano comportamento che si verifica solamente nel caso in cui ci si trovi nelle seguenti condizioni:
Sto effettuando una chiamata ad un Web Service che accetta come parametro un DataSet
Sto utilizzando l'elemento di cifratura nella configurazione del proxy WSE
Utilizzo il Framework 1.1
Il dataSet che sto inviando al server contiene almeno una relazione con constraint tra due tabelle in esso...