Volevo segnalare che uno dei progetti da me coordinati, soluzione basata su SharePoint 2003, è stato appena pubblicato tra i
casi di successo del sito Microsoft. :-)
Pare che le future versioni di Word, Excel e PowerPoint utilizzeranno nativamente un nuovo formato di file XML-based.
Ricordo che l'uscita di Office 12 è annunciato per la metà del 2006.
Per i dettagli leggi la news.
Un ottimo sistema per lavorare con i file archiviati all'interno delle Document Library di SharePoint è quello di accedervi attraverso le FrontPage 2003 RPC.
Si tratta ovviamente di un'altrenativa efficiente alle attualmente più utilizzate strade di WebDAV e Web Service.
Oltre all'esempio più banale di provare a vedere come lavora FrontPage 2003... segnalo un ottimo caso dove le FP2003RPC sono state implementate in un'applicazione.
Si tratta di SharePad, un'applicazione liberamente scaricabile dalla community Got Dot Net.
Il programma gestisce infatti:
- Apertura e salvataggio del file nella Document Library
- Browsing del contenuto delle Document Library
- Gestione del Check-in/Check-out
- Gestione di metadata custom
Sia WSS che SPS espongono un certo numero di Web Service, gran parte dei quali interrogabili anche se si è utenti con accesso anonimo (ma ovviamente almeno appartenenti al Site Group Lettore).
Di seguito provo ad elencare i principali Web Service:
- http://server/_vti_bin/Alerts.asmx - Metodi per lavorare con gli Avvisi (Alerts)
- http://server/_vti_bin/DspSts.asmx - Metodi per interrogare gli schemas ed i dati
- http://server/_vti_bin/DWS.asmx - Aree di lavoro documenti (Document Workspaces)
- http://server/_vti_bin/Forms.asmx - Forms Aspx
- http://server/_vti_bin/Imaging.asmx - Raccolte immagini (Picture libraries)
- http://server/_vti_bin/Lists.asmx - Accesso agli Elenchi (Lists)
- http://server/_vti_bin/Meetings.asmx - Aree di lavoro riunione (Meeting Workspaces)
- http://server/_vti_bin/Permissions.asmx - WSS Security
- http://server/_vti_bin/Sites.asmx - Modelli di sito (Site templates)
- http://server/_vti_bin/UserGroup.asmx - Utenti e Gruppi
- http://server/_vti_bin/versions.asmx - Versioni (versioning) nelle Raccolte documenti (Document libraries)
- http://server/_vti_bin/Views.asmx - Visualizzazioni (Views)
- http://server/_vti_bin/WebPartPages.asmx - Web Parts
- http://server/_vti_bin/Webs.asmx - Informazioni relative ai Sotto siti
Come molti sanno WSS (Windows SharePoint Services) utilizza l'autenticazione integrata di Windows, delegando sostanzialemente ad IIS questo tipo di attività.
L'utente, una volta autenticato, riceve le corrette autorizzazioni (o l'appartenenza ai Site Gorups) grazie alle impostazioni gestite nell'ambito dell'amministrazione di SharePoint.
Volendo è anche possibile configurare il tutto in modo che l'autenticazione sia integrata Kerberos.
Per prima cosa occorre editare con Notepad il file Metbase.xml contenuto nella cartella c:\windows\system32\Inetsrv, agendo all'interno della sezione nominata <IIsWebServer> andando alla ricerca della frase NTAuthenticationProviders="NTLM" e modificandola in NTAuthenticationProviders="Negotiate,NTLM".
Quindi, dopo aver salvato e chiuso il file, riavviare IIS con il comando iisreset da prompt di comandi.
A questo punto occorre seguire alcune varianti, in funzione di come si è installato e configurato WSS, ed in particolare sulla base di quali credenziali di sicurezza sono utilizzate dagli Application pool di del virtual server (o dei virtual server) su cui sono stati estesti i servizi WSS.
Se infatti sono stati utilizzati i service account NT Authority\Servizio di rete o NT Authority\Sistema locale non ci saranno problemi (questi account vengono automaticamente aggiornati a Kerberos), ma (come di solito io consiglio) se fosse stato utilizzato uno specifico service account creato ad-hoc... allora occorrerà andare a modificare le proprietà dell'account.
Inoltre, se il server su cui è installato WSS non è un Domain Controller, ma bensì un server member sarà necessario accedere alle proprietà dell'elemento Computer del server IIS su cui è presente WSS (dal tool Users and Computers di Active Directory) e all'interno della scheda Generico impostare l'opzione Considera attendibile il computer per la delega.
Naturalmente, se si utilizza uno specifico service account servirà autorizzare anche questo rendendolo attendibile per la delega, modificandone le proprietà sempre attraverso Users and Computer di Active Directory, questa volta agendo sull'Utente, e modificando la casella di controllo L'account è trusted per delega dalla scheda Opzioni account.
Se l'identità del pool di applicazioni è un account utente di dominio, è necessario configurare un nome principale del servizio per tale account. Per effettuare tale operazione, attenersi alla seguente procedura:
Setspn -A HTTP/NomeserverDominio\Nomeutente
Il tool Setspn è qui scaricabile.
Qualcuno utilizza il service account NT Authority\Servizio di rete o NT Authority\Sistema locale proprio per semplificarsi la vita... ma quel tipo di configurazione a volte potrebbe essere poco gestibile, ed inoltre è complessa da amministrare quando i DB SQL Server 2000 di WSS risiedono su di un'altra macchina... in questo caso va ricordato che se si volesse ugualmente utilizzare queste credenziali occorrerà modificare le autorizzazioni su SQL Server al fine di garantire all'elemento Dominio\Nomecomputer$ corrispondente al server WSS di disporre dei diritti di DB Creator e DB Owner.
Come già segnalato da RoB, stiamo organizzando un corso residenziale intensivo sullo sviluppo ASP.NET 2.0.
Ora il sito che descrive i dettagli dell'iniziativa è online: http://www.intensivecampus.net
Segnalo anche il corso sarà in una splendida location nelle colline della provincia di Bologna dal 26 al 30 settembre 2005 e che l'Early bird scadrà il 30 giugno 2005.
