In produzione, xml ricevuto non leggibile

Buongiorno,
siamo passati in produzione ed abbiamo iniziato ad eseguire qualche test.
A differenza della fase di test dove ci inoltravamo fatture firmate in xades con il dicke, stiamo testando inviando fatture dal servizio di aruba.

Prima le fatture venivano ricevute pulite mentre ora le fatture sembrano avere problemi

la fattura ci viene inoltrata ma decodificando (base64_decode) la stringa all’interno del tag < file > la prima riga risulta come la seguente

0€	*†H†÷
a €0€10
	`†He < ?xml version="1.0"?><q1:FatturaElettronica versione="FPR12" xmlns:q1="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2">

anche durante la fattura compaiono caratteri non riconosciuti che ci impediscono di validare l’xml che viene quindi rifiutato

avete qualche consiglio ?
il sistema è in php

ho notato che il motivo del problema è il tipo di firma.
fino ad ora tutti i testi li abbiamo eseguiti firmando in xades mentre le fatture che ci è arrivata è in formato cades

Ciao Daniele,
come hai correttamente intuito, probabilmente stai ricevendo un file firmato in cades. Verifica l’estensione del file:

  • .xml: file firmato con xades;
  • .xml.p7m: file firmato con cades.

Ciao Fabio,
ti confermo l’estensione p7m.
Ho risolto o spero di aver risolto, facendo passare il file decodificato per questa funzione

    private function stripP7MData($string) {  
        //$newString=preg_replace('/[\x00\x04\x82\x03\xE8\x81]/', '', $string);
        $newString=preg_replace('/[[:^print:]]/', '', $string);
        // skip everything before the XML content
        $startXml = substr($newString, strpos($newString, '<?xml '));    
        // skip everything after the XML content
        preg_match_all('/<\/.+?>/', $startXml, $matches, PREG_OFFSET_CAPTURE);
        $lastMatch = end($matches[0]);
        $str = substr($startXml, 0, $lastMatch[1]).$lastMatch[0];
        $startAll = strpos($str, "<Allegati");
        if($startAll !== false){
            $endAll = strpos($str, "</Allegati>");
            $str = substr($str, 0,$startAll).substr($str, ($endAll+11) );
        }    
        return $str;
    }

che dovrebbe rimuovere tutti i caratteri “sporchi” e permettere una corretta visualizzazione dell’xml.

purtroppo in produzione l’invio /ricezione va dai 40 minuti alle 3 ore attualmente quindi mi è difficile averne una coferma reale.

Purtroppo non sono un “esperto” di firme e non sono in grado di valutare la correttezza della tua funzione. Io, in alternativa, ho utilizzato il seguente comando da linea di comando (che potresti lanciare da php):

openssl smime -verify -noverify -in 'path/to/IT000000000_00000.xml.p7m' -inform DER -out 'path/to/IT000000000_00000.xml'

Ovviamente questa soluzione richiede l’installazione di openssl sulla macchina se non presente.

1 Mi Piace

Ciao,
anche io ho notato il problema della presenza di questi “caratteri di controllo” che a quanto pare sono supportati dal formato XML https://en.wikipedia.org/wiki/Valid_characters_in_XML (ritengo che per questo motivo il file è ritenuto valido dal SDI anche se in verità avrei qualche dubbio se la presenza di alcuni caratteri sia corretta nel formato XML 1.0).
Ritengo inoltre che la problematica non sia correlata al formato P7M poichè non mi pare che questo preveda l’aggiunta di caratteri controllo all’interno del file originale; per questo motivo io ho inserito il replace anche per tutti gli XML non solo i P7M.
Vero è che questi caratteri sono supportati dall’XML ma francamente non capisco a cosa possano servire e al perchè ci ritroviamo a gestire XML con questi caratteri (ed evito di fare polemiche ma ci sarebbe da discutere …).
Altra cosa che mi preoccupa è la gestione della parserizzazione del XML ed in particolar modo dell’accesso al nodo (by tag name) in presenza di prefix namespace. Ho già verificato che non tutte le fatture hanno il prefix namespace nel root element e non in tutte è lo stesso (Es: <p:FatturaElettronica> ns2:FatturaElettronica ).
Utilizzando il simplexml_load_string otteniamo direttamente il root element e dunque non è importante conoscere il nome del tag che potrebbe essere:

ma i tag successivi potrebbero comunque avere il riferimento al prefix namespace (Es: <p:DatiTrasmissione>) facendo dunque fallire l’accesso al tag per mezzo di $xml->FatturaElettronicaHeader->DatiTrasmissione.
Non avrebbe senso ma a questo punto mi aspetto di tutto.
Saluti.

Invece sì! Come ho già avuto modo di dire in altri thread, ci sono diversi modi in cui si può “costruire” un file .p7m, in particolare è possibile spezzettare il file originario in blocchi, ciascuno dei quali avrà un header all’interno del file p7m. Ci sono alcuni provider che generano file del genere, quindi non si può semplicemente estrarre l’XML dal tag iniziale a quello finale. Bisogna estrarre il contenuto del file firmato con una procedura apposita (alla peggio con openssl se non avete una libreria che lo faccia).

No, non possono esserci. L’unico elemento con namespace è FatturaElettronica, tutti gli altri hanno namespace vuoto.
In ogni caso, il prefisso del namespace è irrilevante. Chi genera il file XML può decidere di usare il prefisso che vuole, oppure non usare il prefisso, specificando il namespace dell’AgE come default, salvo poi ri-specificare il namespace vuoto sugli elementi che stanno sotto a FatturaElettronica.

Il mio consiglio è di usare una libreria XML che gestisca correttamente i namespace. A quel punto basta specificare il namespace http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2 quando si cerca l’elemento root, e il namespace vuoto per tutti gli altri.

Grazie mille per le informazioni.
Saluti.