Il Cross-Origin Resource Sharing (CORS) è un meccanismo che usa header HTTP addizionali per indicare a un browser che un'applicazione Web in esecuzione su un'origine (dominio) dispone dell'autorizzazione per accedere alle risorse selezionate da un server di origine diversa.

Per ragioni di sicurezza, i browser limitano le risposte HTTP esterne che vengono generate all'interno degli scripts. Ad esempio, le Fetch API seguono la same-origin policy, ciò significa che un'applicazione web che utilizza queste API può solamente richiedere risorse HTTP dalla stessa origine di caricamento dell'applicazione, a meno che la risposta dall'altra origine includa i corretti headers CORS.

Tra gli errori più comuni quando si richiedono risorse esterne, come immagini, font o script, e il dominio esterno può avere o non avere abilitato l'header Access-Control-Allow-Origin.

Se non è stato abilitato, l'errore che ci viene restituito dal browser è il seguente:
Access to fetch at 'https://dominioesterno.org' from origin 'https://www.tuodominio.it' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

In questo caso l'header Access-Control-Allow-Origin non è presente e quindi l'unica risposta che è possibile ottenere è una risposta di tipo opaca(opaque).

Il response.type può essere basic, cors o come nel nostro caso opaque, ed informano con vari dati dove la risorsa è stata richiesta e può essere utilizzato per indicare come trattare l'oggetto di risposta.

Con una risposta opaca non saremo in grado di leggere i dati restituiti o visualizzare lo stato della richiesta, il che significa che non possiamo controllare se la richiesta ha avuto successo o meno, ma viene lo stesso memorizzata nella cache(come opaque), la risorsa viene salvata ma non possiamo avere altre informazioni come "Cache-Control", "Content-Language", "Content-Type", "Expires", "Last-Modified" e l'importante "Content-Length", soprattutto quando si ha a che fare con applicazioni web(PWA) e calcolo delle dimensioni della memoria occupata.

Di fatto le dimensioni del file delle risposte conservate nella cache e segnate come opaque vengono calcolate dal browser in modo spropositato facendo aumentare di molto il totale della memoria occupata, di solito pochi KB di risposta vengono calcolati come superiori ai 5 MB o più di spazio occupato, per singola risposta.

Il problema si può risolvere quando invece il server a cui effettiamo la richiesta, ha impostato l'header con Access-Control-Allow-Origin: * che viene indicato come carattere jolly, che permette a chiunque di poter effettuare richieste(l'impostazione classica dei server che forniscono servizi di font o immagini), ma dal browser otteniamo l'errore:
Access to fetch at 'https://dominioesterno.org'' from origin 'https://www.tuodominio.it' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

In pratica l'accesso è possibile ma le credenziali di richiesta non possono essere incluse, per risolvere il problema basta impostare la richiesta senza credenziali, e per ottenere la risposta non opaca impostare la modalità della richiesta in "cors":
fetch('request.url',{'credentials': 'omit','mode':'cors'})

In questo modo non otterremo la risposta opaca e le dimensioni della cache non crescerà a dismisura.

Altri errori che si possono ottenere per la CORS POLICY sono:
The FetchEvent for "https://dominioesterno.org" resulted in a network error response: an "opaque" response was used for a request whose type is not no-cors, ottenuto perchè la fetch è stata impostata con mode 'no-cors'(che restituisce solo risposte opaque), oppure:
Fetch API cannot load https://dominioesterno.org. Request mode is "same-origin" but the URL's origin is not same as the request origin https://tuodominio.it. quando la fetch è stata impostata con mode same-origin che può essere usata solo quando si fanno richieste all'interno delle stesso dominio.

Un altro problema che può essere risolto, sempre riguardante le risposte ottenute e le dimensioni della cache, sono le Response.type segnate come opaqueredirect, in pratica anche quando vengono conservate in cache dei reindirizzamenti(301, 302, ecc), la risposta viene segnata come reindirizzamento opaco e le dimensioni di una semplice redirect supera sempre i 5MB, per eliminare il problema una semplice soluzione è quella di inserire manualmente in cache il reindirizzamento e conservarlo in cache come statico in modo che non venga aggiornato:

var myBlob = new Blob();
var myHeaders = new Headers();
myHeaders.append('Content-Type', 'text/html; charset=iso-8859-1');
myHeaders.append('location', 'https://tuodominio.it/tuadestinazione.html');
var init = { "status" : "301", "headers": myHeaders};
var myresponse = new Response(myBlob,init);

caches.put('https://tuodominio.it/tuoredirect', myresponse);

In questo caso, quando verra chiamato l'indirizzo di redirect, verra richiamato il valore in cache della destinazione, segnato non come opaqueredirect ma come default ma soprattutto con una dimensione corretta.

Se ti è piaciuto l'articolo, clicca su utile, lascia un commento e condividilo sui tuoi social, e al prossimo articolo...

Per i canali dati dedicati, abbiamo nella pratica WebSocket (bidirezionale, Client-Server), RTCDataChannel (bidirezionale, client-client) e Server Sent Events SSE (monodirezionale, Server-Client).

Per praticità e versatilità del servizio SSE, visto che è possibile utilizzarlo in tutti i browser e che può essere implementato anche su un server condiviso ed economico senza tante pretese, risulta uno delle migliori soluzioni per le comunicazioni in tempo reale.

L'idea alla base di SSE può essere spiegata facilmente: un'app Web "si abbona" ​​a un flusso di aggiornamenti generati da un server e, ogni volta che si verifica un nuovo evento, viene inviata una notifica al client, che gestisce gli eventi e aggiorna lo stato.

Prima connessione del client e richiesta servizio:

var evtSource = new EventSource("SSE/serverSent.php",{ withCredentials: true });


Per gestire gli eventi del client:

evtSource.addEventListener('update', function(e) {
$('#SSEMSG').append(e.data);
console.log("SSE: aggiornamento!",e.data);
});

per ogni messaggio che invia il server ci possono essere più listener per gestire eventi diversi che vogliamo aggiornare.

Sul Server, la gestione è semplice:

serverSent.php e lo script che gestisce il servizio, ma può essere implementato con la maggior parte delle tecnologie e linguaggi server.

header('Content-Type: text/event-stream;');
header('Cache-Control: no-cache');
header('X-Accel-Buffering: no');
while (true)
{
RICERCA AGGIORNAMENTI;
echo "event: update".PHP_EOL;
echo 'data: {"utenti":"'.$log["connessi"].'",
"nome":"'.$log["nuovo utente"].'",
"messaggio":"'.$log["messaggio"].'"}'.PHP_EOL;

flush();

sleep(1);
}

un ciclo che tiene aperta la connessione con il client e quando trova aggiornamenti manda un evento, servita con un text/event-stream Content-Type, con un nome dell'evento e il campo data, i dati possono essere inviati anche nel formato JSON.

API MOLTO SEMPLICI, SERVIZIO PRATICO E UTILE.

Se ti è piaciuto l'articolo clicca su utile in basso, e per qualsiasi chiarimento lascia un commento... oppure mandami un messaggio Deskfront

I meccanismi di autenticazione che agiscono sul protocollo HTTP (esempio: cookies) sono tradizionalmente utilizzati in applicazioni web dove il contenuto, o gran parte della business logic, è gestita dal server.

Il meccanismi necessari a rendere il protocollo HTTP stateful hanno due conseguenze negative:
● Riducono la scalabilità: il server deve mantenere in memoria le informazioni di sessione per ciascun utente autenticato in un dato momento
● Aumentano l’accoppiamento tra client e server: La business logic deve essere gestita in larga parte dal server

Nel caso di applicazioni che si appoggiano ad un backend che offre servizi REST API, l’implementazione dell’autenticazione presenta ostacoli aggiuntivi dovuti al fatto che il server in questo caso non “conserverà” alcuna informazione dell’utente perché ogni richiesta è a se stante per definizione (REST = REpresentational “State” Transfer) essendo l’ambiente “Stateless”.

Sono tanti i motivi per preferire architetture REST, come ad esempio la scalabilità (non tenere lo “stato” riduce drasticamente la complessità e le risorse necessarie).

Per evitare, soprattutto per motivi di sicurezza, che l’utente dal client invii ad ogni richiesta le sue credenziali, si possono implementare dei sistemi di autenticazione come il JWT (JSON Web Tokens).

cos’è un JSON?
JavaScript Object Notation (JSON) è un formato di interscambio dati “leggero”, basato su su convenzioni comunemente usate in linguaggi come C++, Javascript, Java, etc.

Perché è così diffuso oggi giorno?
Semplice da leggere per umani e al tempo stesso facile effettuare il parsing in modo automatico.

Basato sul linguaggio Javascript, anche se il tipo di strutture dati che permette di codificare sono comune alla maggior parte dei linguaggi oggi esistenti, permette in particolare di rappresentare:
● Collezioni di coppie chiave-valore (comunemente
usate per definire dizionari, oggetti, hashmap,etc)
● Liste ordinate di elementi (comunemente definiti
come array, vettore, liste, etc)

Cos’è un JSON WEB TOKET
Il principio di funzionamento è mostrato in figura.
● Il token è generato dal server al momento dell’autenticazione
● Il token contiene non solo un identificativo del client, ma tutte le informazioni che servono alla business logic (ex il ruolo dell’utente)
● Il token è firmato dal server e non può quindi essere manomesso

Dato che contiene tutte le informazioni associate ad un utente, il server non deve tenere in memoria i dati relativi alla sessione.
Tradeoff: banda vs. utilizzo memoria del server

Il server può “recuperare” la sessione utente senza mantenerla in memoria e senza effettuare query aggiuntive al database.
Diminuisce l’accoppiamento client-server e aumenta la scalabilità

Il token può essere anche scambiato tra domini differenti in contesti di single-sign-on.
● Un utente può autenticarsi su un determinato dominio A e
ricevere un JWT firmato da A
● Il JWT può essere inviato al dominio B che può verificare (attraverso la firma digitale) se è stato effettivamente generato da A (di cui si fida)
● Il dominio B opera considerando l’utente come autenticato perché il processo di autenticazione è già stato gestito da A

I vantaggi di JWT sono diversi come ad esempio il fatto che per natura un JSON è più sintetico di un XML. Inoltre la maggior parte dei linguaggi di programmazione prevedono una deserializzazione dei JSON direttamente in oggetti ma nessun supporto analogo esiste per l’XML. Ultimo aspetto ma non meno importate è la sicurezza in quanto l’SWT ed il SAML possono essere “signati” solo utilizzando una chiave condivisa simmetrica con tutti i rischi che ne conseguono.

In pratica quando l’utente esegue il login, il sistema verificherà le credenziali ed in caso positivo rilascerà un token che il client dell’utente dovrà usare per ogni successiva richiesta sino allo scadere della validità dello stesso

Nel caso delle NOTIFICHE WEB PUSH
I JWT sono utilizzati per autenticare le richieste al PUSH SERVICE come meccanismi di autenticazione OAuth 2.0, dove il Server della applicazione invia una richiesta di autenticazione al PUSH service, generando un token firmato con la chiave PRIVATA con le informazioni e le invia al server del push service che lo utilizzerà per autenticare la notifica.

Il token di solito è composto da 3 parti che sono la rappresentazione base64url di altrettante sezioni chiamate rispettivamente: Header, Payload e Signature, unite da un PUNTO

Nell’header viene specificato il tipo di token (JWT) e l’algoritmo usato per cifrare, per le notifiche push l’algoritmo scelto è:

Elliptic curve based JSON Web Signatures (ES256 - EC P-256 DSA with SHA-256) dove la firma viene eseguita con la chiave PRIVATA EC (che fa coppia con la chiave pubblica che abbiamo condiviso con il server al momento della sottoscrizione).

Quindi la prima parte:

header = {
“alg”: “ES256”,
“typ”: “JWT”
}

La seconda parte: Il payload conterrà i “claims” ossia delle proprietà ed altre personalizzate che tipicamente dovrebbero contenere al minimo la username o campo simile per identificare l’utente, nell’autenticazione per le push Notification le proprietà necessarie sono 3:

payload = {
"aud" => https://fcm.googleapis.com, //server endpoint
"exp" => time() + 4 * 3600, // scadenza
"sub" => "mailto: mailservizio@email.com” // una email
}

La terza parte (signature) verrà utilizzata per verificare che il token non è stato in alcun modo manomesso e se è stata usata la chiave privata come secret (quindi impiegando una coppia di chiavi public/private asimmetriche), sarà anche possibile stabilire con certezza che l’utente specificato nel token è esattamente chi dice di essere (assumendo che la chiave privata non venga divulgata e quindi solo la parte del sistema che si occupa di generare il token la conosce).

Ovviamente nel payload non vanno inserite informazioni sensibili dell’utente quali ad esempio la password in quanto chiunque in possesso della chiave pubblica sarà in grado di decodificare il token e leggerne il contenuto.

La signature si ottiene utilizzando l’algoritmo di cifratura a cui vengono passate le prime 2 parti già in base64url con la chiave segreta.

Firma = HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

il token quindi sara: base64UrlEncode(header)+”.”+base64UrlEncode(payload)+”.”+base64UrlEncode(firma)

il risultato finale sarà della forma:

eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY
3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdC
I6MTUxNjIzOTAyMn0.tyh-VfuzIxCyGYDlkBA7DfyjrqmSHu6pQ2hoZu
FqUSLPNY2N0mpHb3nk5K17HWP_3cYHBw7AhHale5wky6-sVA

Sito di riferimento: jwt.io

Per maggiori informazioni, Contattaci e non esitare a fare le tue richieste...

Per Attivare le Notifiche Push abbiamo bisogno che l'utente si iscriva al servizio, per fare ciò all'atto della sottoscrizione avviene uno scambio di chiavi tra la nostra APP e il Browser (che gestisce il Push Service che manda materialmente la notifica), visto che i messaggi che manderemo saranno crittografati per evitare intrusioni e possibilità di sniffing.

Quando attiveremo le Notifiche quindi manderemo la nostra chiave pubblica e il Browser ci restituirà la sottoscrizione al servizio con le sue chiavi.

Per il servizio di Notifiche Push è stata scelta la Crittografia e curve ellittiche ECC ed ECDSA per firmare i messaggi, con le prime 256 curve.
le chiavi sono in formato binario e quindi vengono convertite in base64 per poter essere visualizzate ed inviate, ed hanno la seguente forma:

Chiave Pubblica: [viene inviata](inizia sempre per B maiuscolo)
"BG3OGHrl3YJ5PHpl0GSqtAAlUPnx1LvwQvFMIc68vhJU6nIkRzPEqtCduQz8wQj0r71NVPzr7ZRk2f-fhsQ5pK8"
(65 bytes)

Chiave Privata: [viene conservata - segreto]
"Dt1CLgQlkiaA-tmCkATyKZeoF1-Gtw1-gdEP6pOCqj4"
(32 bytes)


Per iniziare a capire è stata creata una pagina web-push-codelab.glitch.me
per poter visualizzare e generare delle chiavi, successivamente si potranno usare delle funzioni con il proprio framework e linguaggio per generarle.

Con PHP per generare le chiavi ECC per il web push protocol, si può usare la funzione:

function createLocalKey()
{
$keyResource = openssl_pkey_new([
'curve_name' => 'prime256v1',
'private_key_type' => OPENSSL_KEYTYPE_EC,
]);

if (!$keyResource) {
throw new RuntimeException('Unable to create the key');
}

$details = openssl_pkey_get_details($keyResource);
openssl_pkey_free($keyResource);

if (!$details) {
throw new RuntimeException('Unable to get the key details');
}

return [hex2bin("04").$details['ec']['x'].$details['ec']['y'], $details['ec']['d']];

}

che restituisce una coppia di chiavi in binario, per poterle visualizzare è quindi necessario convertirle in base64 come specificato in precedenza.

Di seguito una breve introduzione generale sulla crittografia asimmetrica:

La crittografia asimmetrica, conosciuta anche come crittografia a coppia di chiavi, crittografia a chiave pubblica/privata o anche solo crittografia a chiave pubblica, è un tipo di crittografia dove, come si deduce dal nome, ad ogni attore coinvolto nella comunicazione è associata una coppia di chiavi:
La chiave pubblica, che deve essere distribuita;
La chiave privata, appunto personale e segreta;
evitando così qualunque problema connesso alla necessità di uno scambio in modo sicuro dell'unica chiave utile alla cifratura/decifratura presente invece nella crittografia simmetrica.

Il meccanismo si basa sul fatto che, se con una delle due chiavi si cifra (o codifica) un messaggio, allora quest'ultimo sarà decifrato solo con l'altra.

Ci sono due funzioni che possono essere realizzate: cifrare messaggi con la chiave pubblica per garantire che solo il titolare della chiave privata possa decifrarlo oppure usare la chiave pubblica per autenticare un messaggio inviato dal titolare con la chiave privata abbinata.

Cosa significa ECC?
Acronimo di Elliptic Curve Cryptography (Crittografia e curve ellittiche), ECC è un metodo di crittografia delle chiavi pubbliche basato sull'uso di curve ellittiche su campi limitati. La differenza principale tra ECC e RSA è rappresentata dalle dimensioni delle chiavi rispetto alla resistenza crittografica.

ECC fornisce la stessa forza crittografica di un sistema RSA, con chiavi di dimensioni notevolmente inferiori.Le dimensioni ridotte delle chiavi rende ECC e la scelta ideale per i dispositivi con risorse limitate dal punto di vista dell'archiviazione o dell'elaborazione dei dati, aspetto sempre più comune in ambito IoT.

Per maggiori informazioni, Contattaci

Cominciano a diffondersi le PWA, Progressive Web App. Cioè Applicazioni Web Progressive di ultima generazione, che grazie alle loro caratteristiche offrono all'utente una migliore esperienza di uso rispetto alle classiche App.

Le PWA sono una sorta di mix tra una una normale pagina Web ed un'App classica, solo che non si scarica da uno store ma può essere installata sul proprio smartphone, tablet e anche PC direttamente dal Browser di qualsiasi dispositivo.

Quindi in pratica, è un sito web, raggiungibile dal classico Browser tramite www. solo che se visualizzato da un dispositivo mobile, è possibile installare e usare anche off-line come le classiche Applicazioni Native.

Si basano sui cosiddetti "Service Worker", che non sono altro che degli script di codice che lavorano in background e fanno da interfaccia tra l'utente e un browser. Grazie a questo "ponte" di codice le PWA sono multipiattaforma e multidispositivo, quindi possono girare su qualsiasi browser e qualsiasi device, fisso e mobile, purchè il browser sia compatibile con la tecnologia PWA. Inoltre, per loro natura, non sono strettamente dipendenti dalla connessione a Internet. Quindi consumano pochi dati e possono essere usate anche se la connessione è debole o del tutto assente.



I Vantaggi delle PWA

Dalle caratteristiche tecniche delle PWA derivano una serie di vantaggi. Innanzitutto, occupano molto meno spazio sul dispositivo rispetto ad una app tradizionale, perchè solo parte del codice viene scaricato e immagazzinato nella memoria locale mentre il resto viene eseguito non appena c'è connessione.

Poi sono molto veloci, perchè a differenza delle pagine Web non si deve scaricare tutto il contenuto prima che la schermata risponda ai comandi dell'utente. Avendo un indirizzo URL, poi, possono essere trovate dai motori di ricerca e, soprattutto, non dipendono da uno store.

Ciò vuol dire che sono anche più economiche da realizzare per gli sviluppatori, che non devono pagare la percentuale a Google o Apple per la pubblicazione sui rispettivi store ufficiali. Ma non solo: essendo le PWA naturalmente multipiattaforma e multidispositivo, ogni sviluppatore dovrà creare una sola versione dell'applicazione ed essa girerà senza problemi sia su Android che su iOS, ma anche su Windows, Linux e macOS. Infine, lo sviluppatore sarà sempre sicuro che la sua app PWA sarà sempre aggiornata su tutti i dispositivi, perchè si aggiornerà automaticamente non appena il Service Worker otterrà la connessione a Internet.

Vuoi Maggiori informazioni sulle APPLICAZIONI WEB PROGRESSIVE?
Contattami

E se sei uno sviluppatore e vuoi partecipare a discussioni che parlano di PWA iscriviti al gruppo Facebook Progressive Web App PWA ITALIA e se vuoi segui anche la mia pagina ToScoWeb e metti un mi piace... e al prossimo articolo!

Un importante widjet della libreria JQuery User Interface

JQuery Autocomplete

Attiva per gli utenti la possibilità di effettuare una rapida ricerca e selezione da una lista pre-popolata di valori in base al testo inserito, tipo, criteri di ricerca e fitri.

Un aspetto importante riguarda soprattutto la visualizzazione del widjet che inizialmente puà risultare poco semplice, visto la necessità di capire quale elementi modificare per ottenere una completa modifica.

Di seguito una descrizione degli elementi con il relativo codice CSS:

Dimensioni del Widjet
body .ui-autocomplete
{
float: left;
width: 20%;
}

Contenitore delle Selezioni
.fixed-height
{
float: left;
max-height: 175px;
overflow: auto !important;
list-style-type: none;
}

Selezione Singola Interna (TESTO)
.fixed-height li
{
float: left;
width: 100%;
list-style-type: none;
text-align: center;
color: #FFF;
font: bold 26px Poiret One;
}

Selezione Singola Esterna (CONTENITORE)
body .ui-autocomplete .ui-menu-item .ui-corner-all
{
float: left;
width: 100%;
height: 30px;
padding: 10px 0 10px 0;
background: #151268;
}

Selezione Singola al passaggio del Mouse
body .ui-autocomplete .ui-menu-item .ui-state-focus
{
list-style-type: none;
background-color: #00F;
cursor: pointer;
}

Soluzione veloce per chi come me non ha trovato semplice la modifica completa dell'elemento.

Condividi se ti è stato utile e se vuoi lascia un commento cliccando semplicemente nel relativo bottone sottostante