license: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
Dominio whitelisting è un modello di sicurezza che controlla l‘accesso a domini esterni, oltre che l’applicazione non ha alcun controllo. Cordova fornisce una politica di sicurezza configurabili per definire quali siti esterni possono accedere. Per impostazione predefinita, nuove applicazioni sono configurate per consentire l‘accesso a qualsiasi sito. Prima di spostare l’applicazione di produzione, si dovrebbe formulare una whitelist e consentire l'accesso alla rete specifici domini e sottodomini.
Per Android e iOS (a partire dal loro 4,0 comunicati), criteri di sicurezza di Cordova sono estensibile tramite un‘interfaccia del plugin. L’app deve usare cordova-plugin-whitelist, poiché fornisce la migliore protezione e configurabilità rispetto alle precedenti versioni di Cordova. Mentre è possibile implementare il tuo plugin whitelist, non è raccomandato a meno che l'app ha esigenze di politiche di sicurezza molto specifici. Vedere il cordova-plugin-whitelist per dettagli su utilizzo e configurazione.
Per altre piattaforme, Cordova aderisce alla specifica W3C Widget di accesso , che si basa sull‘elemento < accesso > all’interno del file config. xml dell‘applicazione per consentire l’accesso di rete a domini specifici. Per i progetti che si basano sul flusso di lavoro CLI descritto in l'interfaccia della riga di comando, questo file si trova nella directory principale del progetto. Altrimenti per percorsi di sviluppo specifico della piattaforma, posizioni sono elencati nelle sezioni qui sotto. (Vedi le varie guide di piattaforma per ulteriori informazioni su ogni piattaforma).
Negli esempi seguenti viene < access > whitelist sintassi:
Accesso a google.com:
<access origin="http://google.com" />
Accesso al sicuro google.com ( https:// ):
<access origin="https://google.com" />
Accesso per il sottodominio maps.google.com:
<access origin="http://maps.google.com" />
Accesso a tutti i sottodomini su google.com, ad esempio mail.google.com e docs.google.com:
<access origin="http://*.google.com" />
Accesso a tutti i domini, ad esempio, google.com e developer.mozilla.org:
<access origin="*" />
Questo è il valore predefinito per i progetti CLI appena creati.
Essere consapevoli del fatto che alcuni siti Web possono reindirizzare automaticamente dalla loro home page per un url diverso, ad esempio utilizzando il protocollo https o a un dominio specifico paese. Ad esempio http://www.google.com reindirizzerà per utilizzare SSL/TLS a https://www.google.com e poi ulteriormente può reindirizzare a una geografia come https://www.google.co.uk. Tali scenari possono richiedere voci whitelist modificate o aggiuntive oltre il requisito iniziale. Si prega di considerare questo come si stanno costruendo la tua whitelist.
Si noti che la whitelist si applica solo ai principali webview Cordova e non si applica a un InAppBrowser webview o apertura link nel browser web di sistema.
Le regole specifiche della piattaforma whitelisting si trovano in res/xml/config.xml.
Come sopra, vedere cordova-plugin-whitelist per dettagli. Per cordova-android prima 4.0.0, vedere versioni precedenti di questa documentazione.
Come sopra, vedere cordova-plugin-whitelist per dettagli. Per cordova-ios prima 4.0.0, vedere versioni precedenti di questa documentazione.
Le regole di whitelisting si trovano in www/config.xml.
Uso di blackBerry 10 di caratteri jolly si differenzia da altre piattaforme in due modi:
Qualsiasi contenuto accessibile da XMLHttpRequest deve essere dichiarato in modo esplicito. L'impostazione origin="*" non funziona in questo caso. In alternativa, protezione web tutti possa essere disattivata utilizzando la preferenza di WebSecurity descritta in configurazione del BlackBerry:
<preference name="websecurity" value="disable" />
Come alternativa all‘impostazione *.domain, un attributo aggiuntivo subdomains impostato su true. Deve essere impostata su false per impostazione predefinita. Ad esempio, la seguente consente l’accesso a google.com, maps.google.come docs.google.com:
<access origin="http://google.com" subdomains="true" />
Il seguente si restringe l'accesso al google.com:
<access origin="http://google.com" subdomains="false" />
Specificare l'accesso a tutti i domini, compreso il protocollo locale file:// :
(Per ulteriori informazioni sul supporto, vedere documentazione di BlackBerry nell' elemento di accesso.)
Nel sistema operativo Firefox esiste il concetto di whitelisting un dominio specifico. Invece c'è una speciale autorizzazione denominata SystemXHR. È necessario aggiungere questa autorizzazione a config. xml:
<platform name="firefoxos">
<permission name="systemXHR" privileged="true" description="load data from server" />
</platform>
L'oggetto XMLHttpRequest deve essere istanziata con due parametri mozAnon e mozSystem:
var request = new XMLHttpRequest({
mozAnon: true,
mozSystem: true});
Questa soluzione è trasparente, quindi non non c'è nessuna differenza per altre piattaforme.
Le regole di whitelisting per Windows Phone 8 si trovano nel file config. xml dell'applicazione.
Regole di whitelisting si trovano nel file config. xml dell‘applicazione. La piattaforma si basa sullo stesso attributo di subdomains come la piattaforma BlackBerry. (Per ulteriori informazioni sul supporto, vedere documentazione di Tizen sull’ elemento di accesso.)