translation progress database.xml

Author: ManueldG

security/database.xml

@@ -402,57 +402,57 @@ $stmt->execute(["%{$productId}%"]);
 
      <simpara>
       Gli attacchi SQL injection sfruttano principalmente il codice scritto
-      senza fare attanzione alla sicurezza. Non fidarti mai di nessun input, specialmente
+      senza pensare<!--fare attenzione--> alla sicurezza. Non fidarti mai di nessun input, specialmente
       dal lato client, anche se proviene da un menu a tendina,
       un campo di input nascosto o un cookie. Il primo esempio mostra che una query così
       semplice può causare disastri.
     </simpara>
 
      <para>
-      Una strategia di difesa in-depth comporta diverse buone pratiche di scrittura del codice:
+      Una strategia di difesa in-depth comporta diverse Best Practics <!--buone pratiche--> di scrittura del codice:
       <itemizedlist>
        <listitem>
         <simpara>
          Non connettersi mai al database come amministratore o come proprietario. 
-         Utilizzare sempre utenti personalizzati<!-- custom - ad hoc - mirati - appositi --> con privilegi minimi.
+         Utilizzare sempre appositi utenti <!-- custom - ad hoc - mirati - appositi --> con privilegi minimi.
         </simpara>
        </listitem>
        <listitem>
         <simpara>
          Controlla se l'input fornito è del tipo di dati previsto.<!-- controlla --> <acronym>PHP</acronym> ha
          una vasta gamma di funzioni per la convalida dell'input, da quelle più semplici
-         che si trovano in <link linkend="ref.var">Funzioni variabili</link> e
-         in <link linkend="ref.ctype">Funzioni di tipo carattere</link>
-         (es.: rispettivamente <function>is_numeric</function>e <function>ctype_digit</function>
-         ) oltre al supporto per le <link linkend="ref.pcre">Espressioni regolari compatibili con Perl</link>.
+         che si trovano in <link linkend="ref.var">Funzioni variabili</link> e <!-- funzioni variabili -->
+         in <link linkend="ref.ctype">Funzioni tipo carattere</link><!-- funzioni Ctype-->
+         (es.: rispettivamente <function>is_numeric</function> e <function>ctype_digit</function>) 
+         oltre al supporto per le <link linkend="ref.pcre">Espressioni regolari compatibili con Perl</link>.
         </simpara>
        </listitem>
        <listitem>
         <simpara>
-         Se l'applicazione prevede un input numerico, prendi in considerazione la verifica dei dati
+         Se l'applicazione prevede un input numerico, prendere in considerazione la verifica dei dati
          con <function>ctype_digit</function>, modificare con discrezione il suo tipo
-         usando <function>settype</function> o usa la sua rappresentazione numerica
+         usando <function>settype</function> o formattare la sua rappresentazione numerica
          con <function>sprintf</function>.
         </simpara>
        </listitem>
        <listitem>
         <simpara>
-         Se il livello<!--l' interfaccia --> del database non supporta il binding delle variabili, allora
+         Se l'interfaccia <!-- il livello --> del database non supporta il binding delle variabili, allora
          va messo tra virgolette <!--quote--> ogni valore non numerico fornito dall'utente che viene passato al
          database con la specifica funzione di escape del database per le stringhe (ad esempio
          <function>mysql_real_escape_string</function>,
          <function>sqlite_escape_string</function>, ecc.).
          Le funzioni generiche come <function>addslashes</function> sono utili solo
          in un ambiente molto specifico<!--limitato--> (ad esempio MySQL in un set di caratteri a singolo byte
-         con <varname>NO_BACKSLASH_ESCAPES</varname> disabilitato)e quindi è
+         con <varname>NO_BACKSLASH_ESCAPES</varname> disabilitato) e quindi è
          meglio evitarle.
          <function>mysql_real_escape_string</function>,
         </simpara>
        </listitem>
        <listitem>
         <simpara>
-         Non far visualizare informazioni specifiche del database, in particolare
-         lo schema <!-- la struttura -->, <!--con mezzi leciti o illeciti-->a qualunque costo. Vedere anche la sezione <link
+         Non far visualizare a qualunque costo le informazioni dettagliate del database 
+         e in particolare la struttura <!-- schema --> <!--con mezzi leciti o illeciti-->. Vedere anche le sezioni<link
          linkend="security.errors">Segnalazione degli errori</link> e <link
          linkend="ref.errorfunc">Funzioni di gestione e registrazione degli errori</link>.
         </simpara>
@@ -461,12 +461,12 @@ $stmt->execute(["%{$productId}%"]);
      </para>
 
      <simpara>
-      Oltre a ciò, puoi trarre vantaggio dal log <!-- cronologia - report - log - traccia- traking --> delle query da parte del tuo script
-      o, se lo supporta, dal database stesso. Ovviamente, il log non è in grado
+      Oltre a ciò, puoi trarre vantaggio dal log delle query tramite il tuo script <!-- cronologia - report - log - traccia- traking -->
+      o, se lo supporta, attraverso il database stesso. Ovviamente, il log non è in grado
       di prevenire alcun tentativo d'attacco, ma può essere utile per capire quale
       applicazione è stata colpita. Il registro non è utile di per sé, ma
       sono utili le informazioni che contiene. Generalmente più dettagli ci sono nel log meglio è.
-     </simpara><!--XXX traduzione da sistemare -->
+     </simpara>
     </sect2>
    </sect1>
   </chapter>