Security & Architecture : C/C++

Protezione da Buffer Overrun con Visual Studio 2010

mfontana — Thu, 04 Jun 2009 14:21:58 GMT

Segnalo il nuovo posto del team di C++ sulla nuova versione di /gs, gs++ in Visual Studio 2010.

Dal post del team di C++ :

Evolution of GS

A lot of code written in C and C++ has vulnerabilities that leave their users open to buffer overrun attacks. There are two major reasons for this. One reason is that the languages provide unfettered access to the vulnerable memory; the other reason is that developers make mistakes. The simple fact is that even following the best practices and performing quality checks, by the end of the day, no developers can get 100 percent of their code right all the time. Thus, additional built-in layers of defense to help track down vulnerable areas of code are in order. The Visual C++ compiler’s GS switch, which is on by default, is one of the built-in defenses designed to mitigate the buffer overrun attacks. …continua alla fonte.

added : è online anche un video su Channel9 di Louis Lafreniere su Next Generation Buffer Overrun Protection with /GS++

--Mario

Windows Web Services API : Configurazione Certificati e sicurezza per gli esempi con SSL

mfontana — Mon, 30 Mar 2009 14:07:00 GMT

Tutti gli esempi che ho creato nei post precedenti erano su HTTP quindi senza sfruttare la sicurezza di trasporto (SSL). Ora vediamo quali passi sono necessari per configurare la comunicazione su SSL (uso questo esempio su MSDN )

IMPORTANTE !!! In questo post alcune delle configurazioni che faccio sui certificati digitali possono risultare molto pericolose su macchine di produzione… In un ambiente di produzione il rilascio,l’installazione e la manutenzione dei certificati deve essere seguito secondo i processi definiti dalla PKI !! Al contrario, sulle macchine dei sviluppatori spesso risulta necessario farsi delle configurazioni ad hoc per essere autonomi rispetto ai colleghi sistemisti :-) :-). Per facilitare la cosa metterò un tag <WARNING!!> su tutte quelle procedure da non riprodurre in produzione !!

Innanzitutto i passaggi per impostare i progetti client e service e il processo di creazione dei file .c e .h dal wsdl sono sempre i medesimi descritti qui e qui.

Per far si che il nostro Web Service possa utilizzare il protocollo SSL è necessario configurare quale certificato verrà utilizzato per l’inizializzazione del protocollo. Ce lo ricorda anche un commento nel codice presente in tutti gli esempi su MSDN che utilizzano SSL

// NOTE: At the server, the SSL certificate for the listen URI must be
// registered with http.sys using a tool such as httpcfg.exe.

Questa operazione andrà eseguita perchè faremo noi l’hosting del Web Service all’interno di una Win32 console al posto di IIS !!

In questo post utilizzerò l’utility netsh.exe invece di httpcfg.exe

Per prima cosa dovremo procurarci un certificato digitale X509v3. Se non riusciamo ad avere in tempo un certificato da una CA allora seguite questi semplici passi:

<WARNING!!>

usiamo l’utility makecert.exe per creare ed installare il certificato nel certificate store di Windows. (maggiori info sui certificati e sugli store in Windows). Apriamo una console di Visual Studio in Administrator mode e lanciamo :

makecert -r -pe -n "CN= 127.0.0.1" -b 01/01/2009 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

</WARNING!!>

Tramite questo comando abbiamo creato un certificato per “Ensure the identity of a remote computer” e “All issuance policies” ed è stato installato nel certificate store della macchina (local machine). Apriamo la mmc dei certificati e clicchiamo sul certificato in Certificates (Local Computer)->Personal->Certificates e dovremmo vedere una cosa simile a quanto riportato in figura.

a questo punto se proviamo a lanciare il nostro esempio riceviamo il seguente errore :

Failure: errorCode=0x803d0014
There was an error communicating with the endpoint at 'https://127.0.0.1:8999/example’.
The connection with the server was terminated abnormally

questo perchè non abbiamo ancora creato il binding tra l’URI e il certificato digitale nel nostro kernel mode http listener(Http.sys) e quindi il protocollo SSL non può funzionare. Infatti se lanciamo il seguente comando :

netsh http show sslcert

abbiamo una lista dei certificati configurati per SSL con relativo IP:port e hash del certificato! Ovviamente il nostro 127.0.0.1:8999 non esiste. Quindi lo creiamo lanciando il seguente comando :

netsh http add sslcert ipport=127.0.0.1:8999 certhash=a455de0b81ce3251d177d9fb74c62fe237a49ae1 appid={00112233-4455-6677-8899-AABBCCDDEEFF}

In questo caso abbiamo impostato il parametro ipport=127.0.0.1:8999 e certhash con l’hash del nostro certificato appena creato. Per ottenere il valore dell’hash dobbiamo aprire il certificato e alla voce Thumbprint nella tab Details copiare il contenuto. Ricordarsi di togliere gli spazi !!!

se ora rilanciamo il comando

netsh http show sslcert

potremo vedere il nuovo binding sulla porta 8999

Se proviamo ora a lanciare il nostro esempio riceviamo un altro errore:

Failure: errorCode=0x803d000a
There was an error communicating with the endpoint at 'https://127.0.0.1:8999/example’.
The certificate authority is invalid or incorrect

infatti come si vede anche dalla figura 1 il certificato che abbiamo creato ed installato non è valido dal punto di vista della “Certification path”. Per rimediare a questo problema basta copiare il certificato da

<WARNING!!>

Certificates (Local Computer)->Personal->Certificates

a

Certificates (Local Computer)->Trusted Root Certification Authorities->Certificates

</WARNING!!>

a quel punto, se riclicchiamo sul certificato all’interno di Certificates (Local Computer)->Personal->Certificates avremo :

che ci assicura che tutta la “Certification path” è corretta.

Finalmente, se ora lanciamo il Web Service e il client il tutto funziona con il protocollo SSL !!!! Finito?? Non direi :-)

NOOOOO… UN WEB SERVICE CHE GIRA SOLO COME ADMINISTRATOR???

In effetti, se ci fermiamo qui i nostri Web Services girano solo se hanno le credenziali di amministratore !!! Orrore !!! Infatti se creiamo due local Users demo1 e demo2 (aggiungere la policy longon locally se si tratta del server) e dalla nostra console amministrativa lanciamo

runas /user:demo1 cmd.exe (dopo l’invio ci chiede la password)

runas /user:demo2 cmd.exe (dopo l’invio ci chiede la password)

se nella cmd di demo1 ad esempio lanciamo il nostro service (che prima funzionava nella console che gira come admin) avremo come risposta :

Failure: errorCode=0x80070005
Unable to add URL to HTTP URL group.
Access is denied.

Per superare questo ultimo scoglio dobbiamo assegnare i permessi ad un gruppo di utenti (o ad un singolo utente nel nostro caso, per semplicità) per un determinato HTTP URL namespace. Con questa operazione di fatto diamo la possibilità di creare dei servizi di listener su determinati URL a tutti i processi che girano con le credenziali definite. Questa operazione verrà effettuata, ad esempio, durante il processo di installazione dei nostri servizi. Per fare questa operazione lanciamo il comando :

Netsh http add urlacl url=https://127.0.0.1:8999/example user=demo1

e possiamo visualizzare il nuovo namespace reservation tramite il comando :

Netsh http show urlacl

a questo punto se rilanciamo il servizio sempre dalla console demo1 … funzionerà !!! mentre se lo lanciamo dalla console demo2 no !!

La prova del nove? Dalla console amministrativa lanciate il comando:

Netsh http delete urlacl url=https://127.0.0.1:8999/example

che cancella nuovamente la reservation e vedrete che se rilanciate il vostro Web service sempre dalla console demo1 non funzionerà nuovamente :-)

Un paio di Curiosità

1) Dove vengono registrate le info di netsh.exe ?

Tutte le impostazioni vengono salvate nel registy :

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo

e in

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\UrlAclInfo

2) Quali API devo utilizzare per crearmi programmaticamente una URL reservation?

Le API di riferimento sono le HTTP Server API Reference.
Alla fine il tutto si risolve tramite le API

ULONG HttpInitialize( __in HTTPAPI_VERSION Version,
__in ULONG Flags,
__reserved PVOID pReserved );

ULONG HttpSetServiceConfiguration(
  __in  HANDLE ServiceHandle,
  __in  HTTP_SERVICE_CONFIG_ID ConfigId,
  __in  PVOID pConfigInformation,
  __in  ULONG ConfigInformationLength,
  __in  LPOVERLAPPED pOverlapped
);

Stavo per scrivere il wrapper in C# via p/Invoke ma grazie a Keith Brown ho risparmiato almeno un’oretta di lavoro :-). Anche in questo caso, esclusi i vari controlli il tutto si riduce nelle due chiamate alle HTTP API.

// Inizializzazioni varie delle HTTP API

…

// Impostazione delle ACL

int errorCode = HttpInitialize(httpApiVersion,HTTP_INITIALIZE_CONFIG, IntPtr.Zero);

errorCode = HttpSetServiceConfigurationAcl(IntPtr.Zero, HttpServiceConfigUrlAclInfo,ref configInfo, Marshal.SizeOf(typeof(HTTP_SERVICE_CONFIG_URLACL_SET)),IntPtr.Zero);

//Chiamte a Funzioni HTTPAPI di CleanUp…

…

Infine, mi raccomando di ricordarsi di cancellare o disattivare gli utenti locali demo1 e demo2 e di cancellare i certificati quanto prima !!!

--Mario

Windows Web Services API – Come utilizzare gli esempi della documentazione su MSDN

mfontana — Sat, 28 Mar 2009 06:00:00 GMT

Su MSDN ci sono molti esempi di utilizzo delle Windows Web Services API. Per utilizzarli o si scaricano tutti i files di esempio (*.cpp, *.wsdl e makefile) oppure si crea una nuova solution in Visual Studio 2008 al cui interno si creano due applicazioni di tipo console.

Per la seconda opzione consiglio questo ordine :

Prima di tutto createvi una nuova solution contenente due progetti di tipo console e per entrambi togliete il supporto ai precompiled headers e aggiungete al linker la libreria webservices.lib (per il passo passo di queste azioni consultare questo mio post)

Partiamo dal service (prenderò come spunto l’esempio HttpCalculatorServiceExample su MSDN):

Creiamo una directory WSMetadata e creiamo il file CalculatorService.wsdl copiando il contenuto da qui.
Sempre nella directory WSMetadata lanciamo l’utility Wsutil.exe *.* che ci creerà i seguenti files :

CalculatorService.wsdl.c
CalculatorService.wsdl.h
Aggiungiamoli al nostro progetto.
A questo punto nel nostro file Service.cpp copiamo il codice presente qui.
e inseriamo in testa gli #include files

#include <webservices.h>
#include "wsmetadata\\CalculatorService.wsdl.h"

a questo punto possiamo compilare e tutto dovrebbe funzionare :-)

Passiamo al client (riferimento MSDN qui)

Aggiungiamo i files del punto 2 precedente.
A questo punto nel nostro file Client.cpp copiamo il codice presente qui.
Eseguiamo il punto 5 precedente.

Compilatina e anche il client dovrebbe essere pronto. A questo punto lanciate il service e poi il client e la calcolatrice unmanaged funzionerà :-)

--Mario

Windows Web Services API : Step-By-Step per creare un Web Service

mfontana — Fri, 27 Mar 2009 12:10:00 GMT

Nel mio post precedente abbiamo visto come scrivere un client C/C++ capace di invocare un servizio scritto in WCF.

In questo post vedremo come scrivere l’equivalente del servizio WCF in codice unmanaged tramite le WWSAPI.

A differenza della realizzazione di un client il server comporta ovviamente la scrittura a priori del WSDL e degli XSD !!! Questo perchè il linguaggio C/C++ non è così ricco di metadati come il framework .NET !! Quindi per gli amanti del contract-first nessun problema, mentre per i più pigri è sempre possibile definire l’interfaccia in WCF e quindi scaricare i metadati via svcutil /t:metadata :-) (come abbiamo fatto per il client)…

A questo punto possiamo avventurarci nella scrittura del nostro primo Web Service in C/C++

Creiamo un nuovo progetto di tipo Win32 Console Application.
Andiamo nella configurazione del progetto e selezioniamo All Configuration in alto a sinistra nella finestra di Property Page.
1. Selezioniamo Configuration Properties->C/C++ –> Precompiled Headers e alla voce Create/Use Precompiled Header impostiamo : Not Using Precompiled Headers.
2. Selezioniamo Configuration Properties->Linker->Input e alla voce Additional Dependencies scriviamo WebServices.lib.
Premiamo OK alla finestra di configurazione.
Includiamo i .h e .c presenti nella directory WSMetadata.
Aggiungiamo al progetto i files .h e .c presenti nella directory WSMetadata.
Aggiungiamo l’include ai file .h inseriti nel progetto e a <webservices.h>:

#include <webservices.h>
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.xsd.h"
#include "..\\wsmetadata\\schemas.microsoft.com.2003.10.Serialization.xsd.h"
Compiliamo…
Copiamo il codice riportato sotto e poi sempre animati da fiducia… compiliamo :-)

#include <iostream>
#include <conio.h>

// helper routine to print error object
void PrintError(HRESULT errorCode, WS_ERROR* error)
{
printf("Failure: errorCode=0x%lx\n", errorCode);

    if (errorCode == E_INVALIDARG || errorCode == WS_E_INVALID_OPERATION)
    {
        // Correct use of the APIs should never generate these errors
        printf("The error was due to an invalid use of an API. This is likely due to a bug in the program.\n");
        //DebugBreak();
    }

    HRESULT hr = NOERROR;
    if (error != NULL)
    {
        ULONG errorCount;
        hr = WsGetErrorProperty(error, WS_ERROR_PROPERTY_STRING_COUNT, &errorCount, sizeof(errorCount));
        if (FAILED(hr))
        {
            goto Exit;
        }
        for (ULONG i = 0; i < errorCount; i++)
        {
            WS_STRING string;
            hr = WsGetErrorString(error, i, &string);
            if (FAILED(hr))
            {
                goto Exit;
            }
            printf("%.*s\n", string.length, string.chars);
        }
    }
Exit:
    if (FAILED(hr))
    {
        printf("Could not get error string (errorCode=0x%lx)\n", hr);
    }
}

//questa è la vera e propria funzione callback che implementa il metodo Add

HRESULT CALLBACK Add(
    __in const WS_OPERATION_CONTEXT* context,
    __in int a,
    __in int b,
    __out __int64* result,
    __in_opt const WS_ASYNC_CONTEXT* asyncContext,
    __in_opt WS_ERROR* error)
{
    UNREFERENCED_PARAMETER(context);
    UNREFERENCED_PARAMETER(asyncContext);
    UNREFERENCED_PARAMETER(error);

    *result = a + b;
    printf ("%d + %d = %X\n", a, b, *result);
    fflush(stdout);
    return NOERROR;
}

int _tmain(int argc, _TCHAR* argv[])
{

    HRESULT hr;
    WS_ERROR* error;
    hr = WsCreateError(NULL,0, &error);
    if (FAILED(hr)) return -1;

    WS_HEAP* heap;
    hr= WsCreateHeap(1024,0,NULL,0,&heap, error);
    if(FAILED(hr))
    {
        WsFreeError(error);
        return -1;
    }

    wprintf(L"Hosting del mio primo Web Service in C/C++...\n");

BasicHttpBinding_ICalculatorFunctionTable Functions = {Add};

    WS_STRING url = WS_STRING_VALUE (L"http://localhost:8080/NativeCalculatorService");
    WS_HTTP_BINDING_TEMPLATE templateValue = {};
    WS_SERVICE_ENDPOINT* serviceEndpoint;
    hr = BasicHttpBinding_ICalculator_CreateServiceEndpoint (&templateValue,url,&Functions,NULL,NULL,0,heap,&serviceEndpoint,error);
    if(FAILED(hr))
    {
        PrintError(hr,error);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

    WS_SERVICE_HOST* host = NULL;
    const WS_SERVICE_ENDPOINT* serviceEndpoints[1];
    serviceEndpoints[0] = serviceEndpoint;

    hr = WsCreateServiceHost(serviceEndpoints, 1,NULL, 0, &host, error);
    if(FAILED(hr))
    {
        PrintError(hr,error);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

    hr = WsOpenServiceHost(host,NULL,error);
    if(FAILED(hr))
    {
        PrintError(hr,error);
        WsFreeServiceHost(host);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

wprintf(L"Premi Enter per chiudere il servizio...\n");
_getch();

WsCloseServiceHost(host, NULL, error);
WsFreeServiceHost(host);

WsFreeHeap(heap);
WsFreeError(error);

return 0;

}

a questo punto Ctrl+F5 e lanciamo il nostro Web Service e torniamo sul codice client dove andremo a commentare il

#define _WCF

in modo da chiamare il Web Service che abbiamo appena creato. Come si può notare il codice client è il medesimo (salvo l’url) e possiamo invocare indistintamente Web Services scritti in WCF e in C/C++.

La schematizzazione del codice è la seguente :

--Mario

Windows Web Services API : Step->By-Step per il client

mfontana — Thu, 26 Mar 2009 17:21:40 GMT

Il metodo più semplice per provare la nuova libreria WWSAPI è quella di partire da uno scenario WWSAPI client che si integra con un servizio WCF. Passo successivo creeremo lo stesso servizio in C/C++ con WWSAPI e vedremo che lato client ci basterà cambiare l’url del Web Service permettendoci di invocare indistintamente quello sviluppato in WCF e in WWSAPI.

Per crearsi l’ambiente dovremo scaricare il seguente software :

Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 : BETA

Beta of Windows Web Services API for Windows XP, Vista, Server 2003 and Server 2008 (solo se non si sviluppa su WIndows 7 o Windows Server 2008 R2)

Web Service in WCF

Come prima cosa costruiamoci un servizio WCF (tipo di progetto VS2008 : WCF Service Application) che implementa una semplice interfaccia (ovviamente lo si può provare anche con un ASMX) :

namespace CalculatorService
{
    [ServiceContract(Namespace = "http://MarioFontanaPublicDemos.com/CalculatorService/")]
    public interface ICalculator
    {

[OperationContract]
long Add(int a, int b);

}
}

Assicurandoci di impostare il binding su basicHttpBindings. Dovremo avere un web.config simile a questo:

<system.serviceModel>
    <services>
      <service behaviorConfiguration="CalculatorService.CalculatorServiceBehavior" name="CalculatorServiceServiceConfiguration">
        <endpoint address="" bindingNamespace="http://MarioFontanaPublicDemos.com/CalculatorService/Bindings" binding="basicHttpBinding" bindingConfiguration="" contract="CalculatorService.ICalculator">
          <identity>
            <dns value="localhost"/>
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="CalculatorService.CalculatorServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
</system.serviceModel>

A questo punto il nostro servizio dovrebbe avere un WSDL di questo tipo :

Prima di abbandonare il nostro servizio ricordiamoci di rendere fissa la porta su localhost. Nel caso di esempio : 62881 (quindi avremo : l’endpoint su : http://localhost:62881/CalculatorService.svc)

Client C/C++

Per creare il client C/C++ che consuma il nostro servizio WCF dobbiamo fare i seguenti passi :

Ottenere i metadati dal Web Service tramite l’utility svcutil.exe (Microsoft Service Model Metadata Tool)
Trasformare i metadati in dichiarazioni C tramite una seconda utility a riga di comando : wsutil.exe (Windows Web Services Tool) Attenzione : controllate che sia la versione 1.0079. in alcuni casi ho riscontrato che la versione 1.0069 che non funziona !!!
Step succesivo scrivere il codice client.

Vediamo passo passo come fare :

Creiamo un nuovo progetto di tipo Win32 Console Application (può andare anche un qualsiasi progetto con interfaccia grafica, ma sapete io sono un nostalgico della cara vecchia console :-) e premiamo pure su finish perchè non ci interessa nessuna customizzazione.
Andiamo nella configurazione del progetto e selezioniamo All Configuration in alto a sinistra nella finestra di Property Page.
1. Selezioniamo Configuration Properties->C/C++ –> Precompiled Headers e alla voce Create/Use Precompiled Header impostiamo : Not Using Precompiled Headers.
2. Selezioniamo Configuration Properties->Linker->Input e alla voce Additional Dependencies scriviamo WebServices.lib.
Premiamo OK alla finestra di configurazione.
Apriamo una console amministrativa e andiamo nella directory del nostro client. Qui possiamo creare una directory ad esempio : WSMetadata.
Entriamo nella directory WSMetadata e lanciamo la nuova versione dell’utility a riga di comando svcutil.exe /t:metadata <indirizzo del nostro servizio WCF> quindi sarà ad esempio :

svcutil.exe /t:metadata http://localhost:62881/CalculatorService.svc.

In questo modo abbiamo scaricato i metadati dal servizio, ovvero il WSDL e gli xsd, e dovremmo avere un file WSDL e uno o più file XSD. Nel nostro caso avremo

mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl
mariofontanapublicdemos.com.CalculatorService.wsdl
mariofontanapublicdemos.com.CalculatorService.xsd
schemas.microsoft.com.2003.10.Serialization.xsd
A questo punto lanciamo un’altra utility a riga di comando wsutil.exe *.* (assicurarsi che non ci siano altri file oltre quelli creati nel punto precedente perchè altrimenti viene ovviamente generato un errore). Con questa operazione abbiamo creato per ogni file presente nella directory un equivalente .c e .h con la descrizione dello schema, del wsdl e delle policy che andermo ad includere nel nostro progetto. Nel nostro caso avremo quindi 12 files :

mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl
mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.c
mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.h
mariofontanapublicdemos.com.CalculatorService.wsdl
mariofontanapublicdemos.com.CalculatorService.wsdl.c
mariofontanapublicdemos.com.CalculatorService.wsdl.h
mariofontanapublicdemos.com.CalculatorService.xsd
mariofontanapublicdemos.com.CalculatorService.xsd.c
mariofontanapublicdemos.com.CalculatorService.xsd.h
schemas.microsoft.com.2003.10.Serialization.xsd
schemas.microsoft.com.2003.10.Serialization.xsd.c
schemas.microsoft.com.2003.10.Serialization.xsd.h
Aggiungiamo al progetto i files .h e .c appena creati nella directory WSMetadata.
Aggiungiamo l’include ai file .h inseriti nel progetto e a <webservices.h>:

#include <webservices.h>
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.Bindings.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.wsdl.h"
#include "..\\wsmetadata\\mariofontanapublicdemos.com.CalculatorService.xsd.h"
#include "..\\wsmetadata\\schemas.microsoft.com.2003.10.Serialization.xsd.h"
Primo momento della verità : compilatina…e dovrebbe andare tutto OK
Copiamo il codice riportato sotto e poi possiamo compilare nuovamente fiduciosi :-)

#include <iostream>
#include <conio.h>

WCHAR* WsGetErrorDescription(HRESULT hr);

//#define _WCF

int _tmain(int argc, _TCHAR* argv[])
{
    HRESULT hr;
    WS_ERROR* error;
    hr = WsCreateError(NULL,0, &error);
    if (FAILED(hr)) return -1;

    WS_HEAP* heap;
    hr= WsCreateHeap(1024,0,NULL,0,&heap, error);
    if(FAILED(hr))
    {
        WsFreeError(error);
        return -1;
    }

WS_SERVICE_PROXY* serviceProxy;
WS_HTTP_BINDING_TEMPLATE templateValue = {};

    hr = BasicHttpBinding_ICalculator_CreateServiceProxy(
        &templateValue,
        NULL,
        0,
        &serviceProxy,
        error);

    if(FAILED(hr))
    {
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }

WS_ENDPOINT_ADDRESS address = {};

#ifdef _WCF
WS_STRING Url = WS_STRING_VALUE(L"http://localhost:62881/CalculatorService.svc");
#else
WS_STRING Url = WS_STRING_VALUE(L"http://localhost:8080/NativeCalculatorService");
#endif

address.url = Url;
hr = WsOpenServiceProxy(serviceProxy, &address, NULL, error);

    if (FAILED(hr))
    {
        WsFreeServiceProxy(serviceProxy);
        WsFreeHeap(heap);
        WsFreeError(error);
        return -1;
    }
    int a = 1;
    int b = 2;
    __int64 result=0;
    hr = BasicHttpBinding_ICalculator_Add(serviceProxy,a,b,&result,heap,NULL,NULL,NULL,error);

    if (SUCCEEDED(hr))
    {
        wprintf(L"Invocazione del servizio Calculator : %d + %d = %X \n", a,b,result);

    }else
    {
        std::wcerr << static_cast<LPCTSTR>(WsGetErrorDescription(hr)) << std::endl;

        WS_STRING errordesc;
        hr = ::WsGetErrorString(error, 0, &errordesc);
        if (SUCCEEDED(hr))
        {
            std::wcerr << static_cast<LPCTSTR>(errordesc.chars) << std::endl;
        }
        else
        {
            wprintf(L"Ti sei ricordato di attivare il service host??");
        }
    }

_getch();

WsCloseServiceProxy(serviceProxy, NULL, error);

WsFreeServiceProxy(serviceProxy);

WsFreeHeap(heap);
WsFreeError(error);
}

WCHAR* WsGetErrorDescription(HRESULT hr)
{
switch(hr){

                    case WS_S_ASYNC:
                            return L" The function call is completing asynchronously";
                          break;
                    case WS_S_END:
                            return L" There are no more messages available on the channel";
                          break;
                    case WS_E_INVALID_FORMAT:
                            return L" The input data was not in the expected format or did not have the expected value";
                          break;
                    case WS_E_OBJECT_FAULTED:
                            return L" The operation could not be completed because the object is in a faulted state due to a previous error";
                          break;
                    case WS_E_NUMERIC_OVERFLOW:
                            return L" The operation could not be completed because it would lead to numeric overflow";
                          break;
                    case WS_E_INVALID_OPERATION:
                            return L" The operation is not allowed due to the current state of the object";
                          break;
                    case WS_E_OPERATION_ABORTED:
                            return L" The operation was aborted";
                          break;
                    case WS_E_ENDPOINT_ACCESS_DENIED:
                            return L" Access was denied by the remote endpoint";
                          break;
                    case WS_E_OPERATION_TIMED_OUT:
                            return L" The operation did not complete within the time allotted";
                          break;
                    case WS_E_OPERATION_ABANDONED:
                            return L" The operation was abandoned";
                          break;
                    case WS_E_QUOTA_EXCEEDED:
                            return L" A quota was exceeded";
                          break;
                    case WS_E_NO_TRANSLATION_AVAILABLE:
                            return L" The information was not available in the specified language";
                          break;
                    case WS_E_SECURITY_VERIFICATION_FAILURE:
                            return L" Security verification was not successful for the received data";
                          break;
                    case WS_E_ADDRESS_IN_USE:
                            return L" The address is already being used";
                          break;
                    case WS_E_ADDRESS_NOT_AVAILABLE:
                            return L" The address is not valid for this context";
                          break;
                    case WS_E_ENDPOINT_NOT_FOUND:
                            return L" The remote endpoint does not exist or could not be located";
                          break;
                    case WS_E_ENDPOINT_NOT_AVAILABLE:
                            return L" The remote endpoint is not currently in service at this location";
                          break;
                    case WS_E_ENDPOINT_FAILURE:
                            return L" The remote endpoint could not process the request";
                          break;
                    case WS_E_ENDPOINT_UNREACHABLE:
                            return L" The remote endpoint was not reachable";
                          break;
                    case WS_E_ENDPOINT_ACTION_NOT_SUPPORTED:
                            return L" The operation was not supported by the remote endpoint";
                          break;
                    case WS_E_ENDPOINT_TOO_BUSY:
                            return L" The remote endpoint is unable to process the request due to being overloaded";
                          break;
                    case WS_E_ENDPOINT_FAULT_RECEIVED:
                            return L" A message containing a fault was received from the remote endpoint";
                          break;
                    case WS_E_ENDPOINT_DISCONNECTED:
                            return L" The connection with the remote endpoint was terminated";
                          break;
                    case WS_E_PROXY_FAILURE:
                            return L" The HTTP proxy server could not process the request";
                          break;
                    case WS_E_PROXY_NOT_FOUND:
                            return L" The HTTP proxy server does not exist or could not be located";
                          break;
                    case WS_E_PROXY_ACCESS_DENIED:
                            return L" Access was denied by the HTTP proxy server";
                          break;
                    case WS_E_NOT_SUPPORTED:
                            return L" The requested feature is not available on this platform";
                          break;
                    case WS_E_PROXY_REQUIRES_BASIC_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_PROXY_REQUIRES_DIGEST_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_PROXY_REQUIRES_NTLM_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_PROXY_REQUIRES_NEGOTIATE_AUTH:
                            return L" The HTTP proxy server requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_BASIC_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_DIGEST_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_NTLM_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_SERVER_REQUIRES_NEGOTIATE_AUTH:
                            return L" The remote endpoint requires HTTP authentication scheme ";
                          break;
                    case WS_E_INVALID_ENDPOINT_URL:
                            return L" The endpoint address URL is invalid";
                          break;

}

Volendo schematizzare le macro funzioni del codice :

Lanciando prima il Web Service in WCF e poi il nostro clientino dovremmo avere la fatidica risposta della somma !!

Nel prossimo post creeremo lo stesso servizio con le Windows Web Services API per dimostrare la completa interoperabilità tra WCF e WWSAPI.

--Mario

Come integrare vecchi e nuovi applicativi C/C++ con i Web Services

mfontana — Tue, 24 Mar 2009 12:35:18 GMT

Con l’uscita della prima beta di Windows 7 (e Windows Server 2008 R2) sono disponibili delle nuove API – Windows Web Services API (WWSAPI) - che permettono ai programmatori C/C++ di integrare le loro applicazioni “unmanaged” (= non .NET) con il variopinto mondo dei Web Services . Le WWSAPI permettono di creare sia la parte client che la parte server (Web Services) in puro stile C. Le applicazioni C/C++ oggi sono ancora fortemente presenti nei reparti IT e (spesso) non ci sono particolari ragioni per doverle riscrivere in codice .NET o Java!! Quindi le applicazioni C/C++ sono ancora una realtà e come tale è giusto che possano facilmente, ovvero a basso costo e senza overhead, integrarsi con tutti quei Web Services che tanto vanno di moda da qualche anno a questa parte.

Come spesso racconto durante i seminari o durante gli incontri con i clienti l’adozione dei Web Services all’interno di un reparto IT (grande o piccolo che sia) può essere suddiviso in due momenti : Enterprise Efficency ed Enterprise Agility. Nel primo caso stiamo parlando di tutte quelle aziende (ad oggi la maggior parte in Italia) che iniziano a sperimentare l’efficacia dei Web Services e li utilizzano essenzialmente come mezzo per facilitare l’interoperabilità tra software che nativamente non si parlano (spesso per ragioni tecnologiche). Facilitare l’interoperabilità signifca essere più efficienti, da cui Enterprise Efficiency.
Man mano che l’adozione dei Web Services da puro strumento di interoperabilità si trasforma in una architettura adottando quei modelli architetturali che vanno sotto il nome di SOA, EDA, SaaS,... allora entriamo nella così detta Enterprise Agility. Ovvero adottando questi modelli rusciamo ad essere più reattivi alle richieste da parte del business perchè il nostro modello permette o dovrebbe permettere i principi dell’application composition. Bene! Tutto questo panegirico per dire che, una volta tanto, sono qui per parlare della parte di Efficiency e non (solo) della Agility. Infatti tramite le WWSAPI sarà possibile mettere in comunicazione i nostri applicativi unmanaged con servizi scritti con .NET, J2EE e tutti quei linguaggi capaci di gestire SOAP 1.1 o 1.2 e HTTP. In realtà le WWSAPI fanno molto di più : permettono l’integrazione degli applicativi anche in scenari complessi basati su stack WS-* !!!

Ah, quasi dimenticavo, da una indagine svolta dalla società PayScale pare che i programmatori C/C++ abbiano in media uno stipendio più alto dal 2 al 20 % rispetto ai colleghi .NET e Java !!! Programmatore avvisato … :-)

Perchè un’altra libreria?

Perchè le applicazioni unmanaged, essendo una forte realtà sul mercato hanno bisogno di uno stack snello e performante capace di integrare le applicazioni C/C++ con le funzionalità esposte dai Web Services. Inoltre, non so voi, ma a me nel tempo è capitato spesso di vedere molte forme custom di integrazione alcune delle quali particolarmente fantasiose :-) Oramai i Web Services sono diventati una realtà non solo per le applicazioni utenti ma sempre più spesso anche da parte del Sistema Operativo. Quindi, chi meglio del S.O. può mettere a disposizione una libreria capace di “parlare Web Service”??

Altra richiesta fondamentale è la non dipendenza da altri stack tecnologici. Da anni si possono già integrare componenti .NET con codice C/C++ tramite ad esempio il Managed C++, pInvoke.... Tutte soluzioni però che vedono il caricamente del CLR all’interno dello spazio di indirizzamento del processo unamanged. Questo in molti casi è semplicemente non percorribile per motivi di performance, di security... Morale della favola : le WWSAPI non hanno alcuna dipendenza da altri stack tecnologici come COM, DCOM, .NET o altro... nemmeno ATL!!!! Sono delle semplici API esposte in un’unicqa DLL, WEBSERVICES.DLL, che non ha dipendenze particolari se non quelle classiche di sistema come ad esempio :

MSVCRT.DLL (Windows NT CRT)
WS2_32.DLL (Windows Socket 2.0)
HTTPAPI.DLL (HTTP Protocol Stack API)
WINHTTP.DLL (Windows HTTP Services)
CRYPT32.DLL (Prima di Vista)
BCRYPT.DLL & NCRYPT.DLL (Da Vista in poi)

Solo per Windows 7?

Trattandosi tipicamente di applicazioni C/C++ scritte negli anni non era pensabile che il S.O.di riferimento fosse solo ed unicamente Windows 7 e R2 di W2008. Per questo motivo le WWSAPI saranno disponibili anche per tutti i S.O. ancora coperti da supporto tecnico:

Windows XP con Service Pack 2 (SP2) e successivi
Windows Vista
Windows Server 2003 con Service Pack 2 (SP2)
Windows Server 2003 R2 con Service Pack 2 (SP2)
Windows Server 2008

La domanda più ricorrente a questo punto è : perchè non Windows 2000? Perchè ormai W2K è fuori dai cicli evolutivi e di supporto.

Download delle varie versioni : http://connect.microsoft.com/WNDP/content/content.aspx?ContentID=11205

WWSAPI e WCF che relazione?

nessuna :-) ormai dovrebbe essere chiaro. WWSAPI non hanno dipendenze con il framework .NET e quindi neppure con WCF. Sono due librerie paritetiche : WWSAPI utilizzate in codice unmanaged; WCF in codice managed! Condividono però una serie di similitudini come ad esempio il modello di programmazione Function-oriented che permette di mascherare al programmatore i dettagli di una comunicazione message-oriented. Altra similitudine è il supporto a scenari più articolati come quelli previsti dallo stack di specifiche WS-* per i Web Services :

Specifiche di Base:

Trasporto

HTTP, TCP, UDP

XML Encoding

Text, Binary, MTOM

Metadata

WSDL 1.1, XML Schema 1.0

Envelop

SOAP 1.1 e SOAP 1.2

Specifiche WS-*

Addressing

WS-Addressing 0.9 e 1.0

Metadata

WS-MetadataExchange 1.1
WS-Transfer March 2006

Security

WS-Security 1.0 e 1.1 (implementazione parziale)
WS-Trust February 2005 e 1.3 (implementazione parziale)
WS-SecureConversation 1.1 e 1.3 (implementazione parziale)

Policy

WS-Policy dalla versione March 2006 alla 1.2
WS-PolicyAttachment dalla versione March 2006 alla 1.2
WS-SecurityPolicy 1.1

Come si può notare a fianco delle specifiche di sicurezza c’è la scritta un po’ inquietante : implementazione parziale. Questo significa che la versione 1.0 delle WWSAPI implementano solamente la sicurezza a livello di trasporto e Mixed-mode Security escludendo di fatto quella parte delle specifiche relative alla sicurezza a livello di messaggio che al contrario è presente in WCF. Quindi riassumendo le caratteristiche del Channel Security avremo:

Trasport Security:

HTTP : SSL e Header auth: basic/digest/SPNEGO/NTLM e SSPI
TCP: Windows SSPI e SSL

Mixed-mode Security

Il trasporto mette in sicurezza la connessione e fornisce la funzionalità di server authentication.
Gli Header WS-Security all’interno dei messaggi SOAP vengono utilizzati per il client authentication:

Token : Username/Password, Kerberos AP_REQ, SCT, Generic XML
Supporto a token SAML e scenari di Federation.

WWSAPI Architecture

Nella documentazione ancora in BETA ogni tanto si fa ancora riferimento alle WWSAPI con il codename Sapphire !

Nella figura sottostante è schematizzata la struttura delle WWSAPI:

Figura 1 : architettura delle WWSAPI

Esistono una serie di oggetti trasversali ai layer come ad esempio Errors, Tracing, Heap che permettono al programmatore di gestire facilmente alcuni aspetti della gestione delle WWSAPI. L’oggetto Error ad esempio permette di uniformare la gestione degli errori semplificando anche la complessità dei SOAP Faults mentre l’oggetto Heap permette di fare chiarezza su chi alloca e chi disalloca le risorse impiegate per la gestione delle comunicazioni. Maggiori informazioni sull’uso di questi oggetti e relative funzioni si trovano qui

Come si può notare dalla figura 1 il codice applicativo può lavorare a diversi layer a seconda del livello di dettaglio che si vuole gestire direttamente. In due parole cercherò di descrivere i vari layer mentre una descrizione più esaustiva la si può trovare qui sul sito MSDN.

Il Service Model è il layer più ad alto livello che permette di gestire la comunicazione tra il client e il Web Service con il modello a chiamate a funzioni. Il punto di contatto tra il client e un Web Services anche per le WWSAPI è solo il WSDL e gli XSD che vengono trasformati in codice C (.c e .h) da una utility a riga di comando wsutil.exe (Maggiori dettagli nel prossimo post dove partiremo da zero nell’integrazione con dei Web Services).
Lato client permette di chiamare delle funzioni proxy generate dal tool WSutil.exe mentre lato server permette di concentrarsi quasi esclusivamente nell’implementazione delle funzioni di callback.

Il Channel Layer rappresenta una astrazione del canale di comunicazione e permette di interagire direttamente con le sue poprietà. A mio avviso non saranno molti gli scenari dove sarà richiesto l’accesso a questo livello di dettaglio.

L’ XML Layer/Serialization rappresenta il proprio motore specializzato per i’ XML parsing delle WWSAPI con encoding Text, Binary e MTOM. Queste API esportano un XML Buffer, un XML Reader e un XML Writer che permettono di gestire, leggere e scrivere documenti XML solo in modalità “forward-only”. L’unica nota che mi preme sottolineare è il non supporto dei DTD come spesso avviene in scenari SOAP. Anche in questo caso a mio avviso saranno pochi gli scenari dove è richiesto un intervento a questo livello.

Nel prossimo post vedremo come utilizzare queste API passo-passo in diversi scenari…

--Mario