Configurare un proxy SOCKS over SSH con putty e firefox per aggirare il proxy aziendale

In questa guida vedremo come configurare una connessione ssh in modo da ottenere un proxy SOCKS. Essa può essere utile per by-passare il proxy aziendale e navigare anche su siti normalmente bloccati e, quindi, inaccessibili.

Requisiti di fattibilità sono:

  1. avere un pc linux a casa con un server ssh in ascolto sulla porta 22
  2. avere la porta 22 dalla intranet non bloccata verso internet
  3. conoscere l’ip del server (anche tramite dns dinamico come dyndns) e impostare il ruoter con port forwarding sulla porta 22 verso il pc linux
  4. avere un pc client con installato il client putty e il browser firefox

Iniziamo con il configurare correttamente il client ssh putty, per fare ciò dobbiamo conoscere l’ip pubblico del pc linux su cui è installato il server ssh, lasciamo impostata la porta 22, connection type selezionato su ssh e diamo un nome alla connessione (tipo “TUNNEL”); dopodiché facciamo Save.


Successivamente, dal menu a sinistra, selezioniamo connection. Nel campo “Seconds between keepalives” impostiamo 1 e flagghiamo le 2 opzioni sotto, principalmente “Enable TCP keepalives“.

putty connection

 

Da connection spostiamoci nel sottomenu connection->proxy e inseriamo i dati del proxy a cui siamo collegati per andare su internet specificando il tipo di proxy, l’ip o il nome del proxy, la porta su cui è in ascolto e le credenziali, se ci sono.

putty proxy

 

Nel menu connection->SSH->Tunnels valorizziamo il campo “Source port” con una porta a nostra scelta ma superiore alla 1024 (ad es. la 5000), sulle opzioni sotto scegliamo “Dynamic” e “Auto” e clicchiamo su “Add“: comparirà nel box l’indicazione Dxxxx dove xxxx è la porta scelta.

putty tunnel

Infine, torniamo nel menu session e facciamo salva per memorizzare i parametri. Tutti i parametri per la connessione e il relativo tunnel sono impostati, quindi facciamo click su “Open” per far partire la connessione e inseriamo nome utente e password. Se non ci sono stati intoppi la connessione con il server è instaurata e il tunnel ssh è già in funzione.

Il passo successivo è la configurazione di firefox per utilizzare il tunnel come un proxy SOCKS. Dal browser andiamo sul menu strumenti->opzioni->avanzate->rete, troveremo la voce “Determina come firefox si collega a internet” e clicchiamo su impostazioni. Si aprirà una nuova finestra dove dovremo impostare “Configurazione manuale dei proxy” e valorizziamo solamente la voce Host SOCKS con il valore 127.0.0.1, come porta quella impostata nel tunnel (nell’esempio è la 5000) e selezioniamo SOCKSv5.

impostazione proxy firefox

Facciamo ok. Se la configurazione è terminata correttamente, una volta instaurata la connessione ssh potremo navigare con firefox utilizzando il nostro pc linux di casa finché non verrà chiusa la connessione.
Ovviamente, la configurazione del proxy può essere cambiata non solo su firefox ma su un qualsiasi browser o programma che consentono di inserire a mano le impostazioni proxy, come ad esempio explorer, skype, antivirus e torrent.

Nel caso in cui il firewall aziendale blocchi la porta 22 basterà modificare la porta di ascolto del servizio ssh (e il relativo port forwarding sul router di casa) sulla porta 80 o sulla porta 443 verso il pc linux dato che tali porte saranno sicuramente aperte.

Configurare server ftp su ubuntu linux

Per configurare un semplice server ftp su ubuntu linux utilizziamo vsftpd.

sudo apt-get install vsftpd

Dopo l’installazione editiamo il file di configurazione di vsftpd

sudo nano /etc/vsftpd.conf

e decommentiamo/configuriamo i parametri

anonymous_enable=NO
local_enable=YES
write_enable=YES

Tali comandi servono per disabilitare l’accesso in maniera anonima, abilitare l’accesso da locale e consentire la scrittura agli utenti. Per rendere effettive le modifiche riavviamo il demone

sudo /etc/init.d/vsftpd restart

e proviamo a collegarci come client al server ftp da linea di comando o tramite programmi come filezilla.

Tags: , , , ,

Configurazione server ssh su ubuntu linux

Questa guida mostra la configurazione (se pur con impostazioni minime) di un server ssh su ubuntu linux utilizzando OpenSSH. Per prima cosa installiamo OpenSSH

sudo apt-get install openssh-server

Successivamente editiamo il file sshd_config

sudo nano /etc/ssh/sshd_config

e modifichiamo il valore della riga seguente per non permettere il login come root

PermitRootLogin no

decommentiamo la riga e modifichiamo con

IgnoreUserKnownHosts yes

per concedere il login solo con l’immissione di uno username e di una password e, infine, inseriamo gli utenti che possono accedere

AllowUsers nome_utente1 nome_utente2

Per rendere effettiva la configurazione restartiamo il demone ssh

sudo /etc/init.d/sshd restart

Se tutto è andato a buon fine sarà possibile collegarsi da remoto sul pc utilizzando un client ssh come putty.

Tags: , , , ,

Migrare prestashop da un dominio ad un altro

Questa procedura serve nel caso vogliate spostare il vostro sito prestashop da un dominio ad un altro, ad esempio per un cambio di servizio di hosting. La procedura permette di migrare completamente il vostro sito con tutti i prodotti e i plugin installati.

  • Per prima cosa rendete offline il vostro e-commerce prestashop così da non creare inconsistenza nel caso ci siano azioni da qualche utente mentre si effettua la migrazione. Per fare ciò, nel pannello di amministrazione (back-office), fare:
    Preferenze -> Manutenzione -> Attiva negozio -> NO
  • Successivamente effettuate un backup (dump) del vostro database prestashop, lo potete tranquillamente fare con phpmyadmin tramite il comando esporta
  • Dopo il DB è necessario esportare anche i file, quindi spostare tutti i file presenti nella directory di prestashop dal vecchio al nuovo dominio compresi i file nascosti. E’ possibile scaricare i file in locale per poi rifare l’upload sul nuovo server oppure trasferirli direttamente da un server all’altro attraverso il protocollo FTP. Questa operazione può durare molto tempo, anche ore se il vostro e-shop contiene molti articoli
  • A questo punto ci spostiamo definitivamente sul nuovo server, la prima operazione da fare sul nuovo server è l’import del backup del database fatto precedentemente, anche in questo caso è possibile utilizzare il tool phpmyadmin
  • Dopo aver ricaricato il DB andiamo a modificare il file di configurazione di prestashop che si trova in config/settings.inc.php, in particolare vanno modificati i parametri relativi al database:
    1. define('_DB_SERVER_', 'mioServerDatabase');
    2. define('_DB_NAME_', 'nomeDelDB');
    3. define('_DB_USER_', 'utenteDB');
    4. define('_DB_PASSWD_', 'passwordDB');
    5. define('_DB_PREFIX_', 'ps_');

    Il punto 5 è il prefisso standard di prestashop per la creazione delle tabelle, non va modificato a meno che non sia stato cambiato nella precedente installazione. Se la versione utilizzata è precedente la 1.4 va modificata anche un’altra voce:

    • define('__PS_BASE_URI__', '/cartellaInstallazione/');
  • Entriamo nel pannello di amministrazione per modificare gli URL relativi al nuovo dominio nella pagina Preferenze -> URL e SEO modificando le voci “Dominio negozio“, “Dominio SSL” e “URL principale” (quest’ultima va inserita nel caso in cui prestashop non sia installato nella directory principale del sito ma in una sottocartella e va popolata con il nome della cartella di installazione. Ad es. “/shop/” se prestashop è installato nella directory shop).
    Bisogna anche rigenerare il file robots.txt cliccando sul punsante che trovate nella stessa pagina.
  • Infine, riattiviamo il negozio
    Preferenze -> Manutenzione -> Attiva negozio -> SI

A questo punto, se non ci sono stati errori o problemi di varia natura, dovremmo poterci collegare al nostro e-commerce prestashop sul nuovo dominio con una copia speculare di quello che era installato sul precedente server.

Funzionamento del protocollo OSPF

L’Open Shortest Path First (in seguito, OSPF) è un protocollo di routing link state pubblico e non proprietario.

I router che utilizzano protocolli link state identificano i propri vicini e comunicano con essi. L’OSPF raccoglie le informazioni dai router vicini circa lo stato dei link di ognuno di essi e invia i suoi dati agli altri. Questo scambio di informazioni sullo stato dei link permette ai router di creare la topology table o (link state database). Ogni router nella stessa area OSPF ha la stessa topology table e viene usata per calcolare la rotta migliore fino a una destinazione applicando l’algoritmo SPF (Shortest Path First). L’algoritmo SPF si basa sul costo che è principalmente basato sulla larghezza di banda; il percorso a costo più basso viene inserito nella routing table (o forwarding database).
Ogni router mantiene una lista di router vicini chiamata adjacency database. Tale lista è formata da tutti i router vicini con cui un router stabilisce una comunicazione bidirezionale ed è unica per ogni router. Per ridurre il numero di informazioni di routing scambiate tra i vicini all’interno della stessa rete, i router OSPF eleggono un designated router (DR) e un backup designated router (BDR) che vengono utilizzati come punti focali per lo scambio di informazioni di routing.

L’OSPF è un protocollo da utilizzare in reti estese e scalabili dove i limiti dei protocolli distance vector rendono improponibile utilizzarli, sia per utilizzo di metriche non basate sulla larghezza di banda che per la lenta convergenza del protocollo (in reti estese il RIP può avere la convergenza di alcuni minuti). Le principali differenze sono state già trattate in altri articoli.

OSPF si interfaccia con le reti broadcast multi-access (come l’Ethernet), pont-to-point e Nonbroadcast multi-access (NBMA, come il Frame Relay). Le reti di tipo point-to-multipoint possono essere configurate manualmente su un’interfaccia dall’amministratore.
In una rete multi-access non si conosce il numero di router a cui si è connessi, mentre nel collegamento point-to-point solo due router possono essere connessi. In una rete broadcast multi-access il numero di adiacenti può essere elevato e varia in base al numero di router della rete. In generale se N è il numero di router il numero di potenziali adiacenti sarà dato dalla formula

N*(N-1)/2

e ciò provocherebbe molto overhead. La soluzione di questa problematica sta nell’eleggere un DR che diventa adiacente di tutti gli altri router nel segmento di broadcast, quindi tutti i router inviano i LSA al DR ed esso invierà le informazioni  a tutti i router del segmento usando l’indirizzo multicast 224.0.0.5. Questa soluzione è efficiente ma presenta lo svantaggio che il DR funge come centro stella, quindi con problemi per la rete in caso di rottura. Per questo viene eletto un BDR tra i designated router. Per garantire la sincronizzazione delle informazioni tra DR e BDR vengono inviate le informazioni all’indirizzo 224.0.0.6.
Ovviamente in una rete point-to-point ci sono solo due nodi e non esistono né DR né BDR: entrambi i router hanno le complete adiacenze con l’altro.

Quando viene avviato un processo di routing OSPF su di un’interfaccia, il router manda pacchetti “hello” a intervalli regolari (Hello protocol) attraverso l’indirizzo 224.0.0.5 che invia il pacchetto a tutti i router OSPF. Tali pacchetti (molto piccoli, hanno solo un OSPF header) vengono inviati ogni 10 secondi di default, ogni 30 per reti NBMA e sono importanti poiché attraverso essi vengono eletti il DR e il BDR.

Funzionamento

Come già accennato, l’avvio di un processo OSPF su di un’interfaccia fa si che il router invii pacchetti hello a intervalli regolari; le regole che governano lo scambio di pacchetti hello viene chiamato hello protocol. In una rete multi-access l’hello protocol fa si di eleggere un DR e un BDR. I pacchetti hello trasportano le informazioni e tutti i vicini devono essere sincronizzati per formare adiacenze e scambio di informazioni sullo stato dei link. In reti multi-access sono il DR e il BDR a dover mantenere le adiacenze con tutti gli altri router OSPF.

I router adiacenti attraversano una sequenza di stati. Prima di formare la routing table i router adiacenti devono essere a conoscenza della topologia dell’intera rete. Ogni router invia LSA nei Link State Update (LSU) e tale LSA contiene al suo interno tutte le informazioni sui link del router; viceversa, ogni router riceve un LSA da ogni vicino per formare il topology database. Tale processo si ripete per ogni router della rete OSPF.

Quando il database è completo ogni router applica l’algoritmo SPF per calcolare una topologia logica esente da loop per ogni rete di destinazione da inserire nella routing table. Le informazioni di routing sono così fissate; quando vi è la variazione dello stato di un link, i routers usano un processo di flooding per notificare agli altri router della rete il cambiamento. Inoltre, per verificare se un adiacente è down, l’hello protocol impone un dead interval.

Link state routing protocol

Abbiamo già visto in un precedente articolo quali sono le principali differenze tra i protocolli di routing distance vector e i protocolli link state. In questo articolo continuiamo la trattazione e vedremo nel dettaglio le caratteristiche dei protocolli link state; prima, però, riprendiamo le differenze tra le due classi di protocolli di routing.

I protocolli distance vector (come RIP e IGRP) presentano le seguenti caratteristiche:

  • inviano l’intera tabella di routing ai router vicini;
  • aggiornamenti periodici frequenti;
  • metrica basata sui salti (solo il RIP);
  • vedono la rete dalla prospettiva dei vicini;
  • convergenza lenta;
  • possibili routing loops;
  • semplicità di configurazione;
  • alto consumo di banda.

Caratteristiche dei protocolli link state:

  • aggiornamenti al variare della topologia della rete;
  • uso dello Shortest Path;
  • invio di pacchetti link-state a tutta la rete (LSA, Link State Advertisement);
  • vista totale della rete in comune tra i router;
  • convergenza veloce;
  • non suscettibili di routing loops;
  • complessi da configurare;
  • richiedono molta memoria e potenza computazionale;
  • consumano poca banda.

Un router che utilizza protocolli link state colleziona le informazioni da tutti gli altri router nella rete e, successivamente, calcola il miglior percorso (SPF algorithm) per tutte le destinazioni della rete stessa. Le variazioni della rete vengono acquisite dai router in maniera veloce: le informazioni vengono inviate in maniera non periodica ma al variare della topologia (triggered updates). Inoltre, vengono inviati dei pacchetti “hello” per verificare la raggiungibilità dei vicini. Informazioni di “hello” e LSAs costituiscono lo strumento per conoscere la topologia della rete per poter creare la tabella di routing (routing table).

Quando vi è una rottura nella rete si ha un fooding di pacchetti LSAs a un indirizzo multicast dedicato; ogni router invia queste informazioni su tutte le porte tranne su quella in cui l’informazione è arrivata. Questo fa si che ogni router appartenente a una certa area debba ricalcolare le rotte, ecco perché il numero di router di un’area deve essere limitato.

Un link è un’interfaccia del router. Lo stato di un link è la descrizione dell’interfaccia e della relazione con i router vicini. La descrizione dell’interfaccia può includere l’indirizzo IP della stessa, la subnet mask, il tipo di rete a cui è connessa, i router connessi ecc. L’insieme di tali informazioni forma il database link state meglio conosciuto come database topologico (topological database). Applicando l’algoritmo di Dijkstra (SPF, Shortest Path First) si forma un albero SPF in cui il router che lo applica è la radice (root). Il percorso migliore calcolato viene inserito nella routing table.

Vediamo di riassumere i vantaggi e gli svantaggi dei protocolli link state. Vantaggi:

  • utilizzo del costo di un link come metrica che tiene conto della capacità del link;
  • utilizzo di LSAs per informare immediatamente gli altri router dei cambiamenti della topologia della rete così da avere un convergenza veloce;
  • vista completa della rete, i routing loops sono facilmente evitabili;
  • routing table sempre aggiornata in base alle ultime informazioni ricevute;
  • supporto a CIDR e VLSM.

Svantaggi dei protocolli link state:

  • richiedono maggiore memoria e potenza di calcolo rispetto ai protocolli distance vector. Questo può determinare un costo eccessivo per un’azienda con poco budget o con hardware datato;
  • richiedono una struttura gerarchica della rete per poterla suddividere in aree più piccole e gestibili riducendo la dimensione della topology table;
  • richiedono una buona conoscenza del protocollo da parte dell’amministratore di rete;
  • effettuano un flooding di LSAs durante il processo di discovery iniziale che può determinare un significativo calo della capacità della rete in questo periodo.

RIP v2 e default routes su router cisco

In questo articolo terminiamo la trattazione sul RIP iniziata nei precedenti articoli, RIP e configurazione sui router cisco e RIP: load balancing e integrazione delle rotte statiche, fornendo una comparazione tra il RIPv1 e il RIPv2.

Entrambe le versioni di RIP sono dei protocolli distance vector, sono facili da configurare e usano l’hop count come metrica (dopo 15 hop la rete viene posta come irraggiungibile), usano l’holddown timers e lo split horizon per evitare i routing loops. I router hanno conoscenza delle sottoreti direttamente connesse e gli aggiornamenti includono informazioni sulla topologia (almeno la metrica); tali aggiornamenti avvengono in maniera periodica.

Il RIPv2 apporta dei vantaggi rispetto alla prima versione del protocollo. In particolare il RIPv2:

  • supporta il classless routing;
  • include nei routing updates le subnet mask;
  • ha un meccanismo di autenticazione negli updates (utilizza la criptatura MD5);
  • invia gli aggiornamenti in multicast (indirizzo 224.0.0.9) anziché in broadcast;
  • usa un routing tag con VLSM.

La configurazione del RIPv2 è identica a quella del RIPv1, l’unica differenza sta nell’inserire il comando version 2, come da esempio sotto:

Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network network-number

Per la verifica della configurazione si possono utilizzare i comandi show ip protocols, show ip route e show ip interface brief oltre, ovviamente, a show running-config. Il troubleshooting del RIPv2 può avvenire con il comando debug ip rip mentre per disattivare il debug basta inserire no debug all oppure undebug all.

Prima di concludere parliamo della rotta di default (default route). In generale, un router apprende il percorso verso una data destinazione in tre modi: attraverso una rotta statica (l’amministratore inserisce manualmente la rotta), con una rotta dinamica (grazie agli aggiornamenti inviati secondo un protocollo di routing) oppure per mezzo di una default route.
L’amministratore di rete può definire manualmente una rotta di default, cioè il percorso da seguire nel caso in cui non conosca alcuna rotta per raggiungere la destinazione. La rotta di default porta come vantaggio l’avere una ridotta tabella di routing e un percorso di default per destinazioni non conosciute.
La default route può essere impostata dal comando ip default-network in reti che utilizzano routing dinamico:

Router(config)#ip default-network rete

ad es.:

Router(config)#ip default-network 192.168.10.0

oppure attraverso una rotta statica, ad es.:

Router(config)#ip route 0.0.0.0 0.0.0.0 s0/0

dove gli zeri sia nel campo ip che nella subnek mask indicano ogni rete di destinazione con qualsiasi maschera. L’s0/0 è interfaccia su cui inviare i pacchetti (nell’esempio la seriale 0, dovete modificarla in base alle vostre esigenze).

VLSM, CIDR e aggregazione delle rotte

La Variable-length subnet mask (VLSM) è una tecnica utilizzata dagli amministratori di rete per usare in maniera più efficiente gli indirizzi IP. Con la VLSM si offre una maschera più lunga a reti con molti host e una maschera più corta per reti con pochi host, ovvero la maschera varia a seconda del numero di indirizzi necessari a quella rete.
Per implementare la VLSM bisogna, ovviamente, utilizzare un protocollo di routing che supporta il classless routing (un protocollo che, invece, non supporta le VLSM viene detto classful). I protocolli di routing classless su cui utilizzare la VLSM nei router cisco sono:

  • OSPF
  • Integrated IS-IS
  • EIGRP
  • RIP v2
  • BGP v4
  • Routing statico

I protocolli di routing classful sono, invece:

  • RIP v1
  • IGRP
  • EGP
  • BGP v3

Il classless routing nasce per il problema della carenza di indirizzi IP dovuto al veloce aumento delle dimensioni delle tabelle di routing di Internet. Le soluzioni a questo problema sono state il subnetting, la VLSM appunto, il Classless Interdomain Routing (CIDR), l’utilizzo di indirizzi IP privati e il Network Address Translation (NAT). La soluzione definitiva sarà l’utilizzo del protocollo IPv6 che avrà un’astensione di 128bit per gli indirizzi di rete (quindi uno spazio di indirizzamento enorme).

In principio era stato deciso di non utilizzare né la prima (subnet zero) né l’ultima subnet (all-one subnet), successivamente è stato consentito l’uso anche di tali subnet, soprattutto in unione alle VLSM. Per non utilizzare la prima subnet sui router cisco basta digitare il comando no ip subnet-zero.

Le VLSM sono utilissime per utilizzare in maniera efficiente subnet con pochi host, in particolare per i collegamenti Point-to-Point con i WAN links in cui si può usare una maschera di 30 bit (/30) con 2 soli host utilizzabili.
Inoltre, l’uso di CIDR e VLSM permette di effettuare l’aggregazione delle rotte o summarization. Tale tecnica consiste nel fornire al router di uscita di una grande organizzazione (ad es. un ISP) un indirizzo che riepiloga le sottoreti raggiungibili da esso riducendo così il carico sul router. Per fare ciò è necessario che gli indirizzi vengano assegnati in maniera gerarchica in modo che gli indirizziriassuntivi” condividano lo stesso ordine superiore bit.

Utilizzare lightbox su immagini caricate con innerHTML

Il lightbox è un’applicazione javascript per la visualizzazione delle immagini in maniera elegante. Per maggiori informazioni sull’utilizzo e per il download dei files andate qui.

Il lightbox è uno strumento molto utilizzato. Di recente mi è capitato di dover utilizzare il lightbox su immagini caricate dinamicamente all’interno di un div; dopo svariate prove sono giunto a utilizzare la seguente funzione javascript:

<script type="text/javascript" language="javascript">
function showImage(w,h,image) {
 var obj=document.getElementById("id_div");
 obj.innerHTML="";
 obj.innerHTML+="<a href='"+image+"' rel='lightbox'><img src='"+image+"' width='"+w+"' height='"+h+"'></a>";
 initLightbox();
 }
</script>

<div id="id_div">
</div>

La funzione showImage() va a scrivere all’interno del div con id uguale a “id_div” inserendo sia il tag <a> che il tag <img> con il metodo innerHTML, passando anche l’altezza e la larghezza che dovrà avere l’immagine. Ovviamente per poter far funzionare il lightbox bisogna inserire all’interno del tag <a> l’attributo rel=”lightbox”.
Dopodiché bisogna reinizializzare il lightbox tramite la funzione initLightbox(), questo accade perché ogni variazione dinamica dell’HTML sul codice delle immagini richiede la reinizializzazione del lightbox.
Nota: il primo innerHTML con argomento vuoto serve a evitare che le chiamate della funzione successive alla prima abbiano come effetto la sovrapposizione delle immagini precedentemente caricate.

Un’altra soluzione molto simile alla prima è la seguente:

<script type="text/javascript" language="javascript">
function showImage(w,h,image) {
 var obj=document.getElementById("linkID");
 var objIMG=document.getElementById("imgID");
 obj.href=image;
 objIMG.src=image;
 objIMG.width=w;
 objIMG.height=h;
 initLightbox();
 }
</script>

<div id="id_div">
<a id="linkID" rel="lightbox"><img id="imgID"  /></a>
</div>

La differenza rispetto al caso precedente sta nell’inserire a priori all’interno del div i tag <a> e <img> e nell’inserire dinamicamente i contenuti degli attributi.
L’utilizzo della funzione è molto semplice, basta richiamarla in un qualsiasi punto della pagina web, ad esempio tramite onclick dentro un tag.

Entrambe le soluzioni proposte sono state testate su firefox 4/5 e su IE9.

Inserire codice youtube in sito web senza errori di validazione W3C

L’inserimento dei video youtube all’interno di un sito web è un’operazione molto semplice: youtube stesso, infatti, definisce il codice da incorporare all’interno della pagina web. Il codice può essere del tipo:

<iframe width="560" height="349" src="http://www.youtube.com/embed/xxxxxxxxxxx" frameborder="0" allowfullscreen></iframe>

oppure

<object width="560" height="349"><param name="movie" value="http://www.youtube.com/v/xxxxxxxxxx?version=3&amp;hl=it_IT"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/xxxxxxxxxxx?version=3&amp;hl=it_IT" type="application/x-shockwave-flash" width="560" height="349" allowscriptaccess="always" allowfullscreen="true"></embed></object>

Cosa accade però se il sito deve essere accessibile?
In questo caso la situazione si complica.

Purtroppo, così come sono i due codici daranno errore sul W3C Validator, il primo per l’utilizzo del tag <iframe> e del tag <embed>, il secondo solo per l’utilizzo del tag <embed>. Non essendo possibile modificare il primo bisogna cercare di modificare il secondo codice togliendo il tag <embed>.
La soluzione è quella di usare il seguente codice:

<object width="560" height="349" type="application/x-shockwave-flash" data="http://www.youtube.com/v/xxxxxxxxxx"><p>Descrizione</p><param name="movie" value="http://www.youtube.com/v/xxxxxxxxxxx"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param></object>

Ovviamente al posto delle xxxxxxxxxxx va inserito il codice del video. In questo modo potrete inserire i video di youtube anche in siti accessibili.
NB: ricordatevi di inserire la descrizione del video all’interno del tag <object> e prima del tag <param>; essa serve nei casi in cui il video non può essere caricato.