Lorsque j'essaie de changer la référence liée d'un fichier JavaScript local en une version brute de GitHub, mon fichier de test cesse de fonctionner. L'erreur est:

Refus d'exécuter le script à partir de ... car son type MIME ( text/plain) n'est pas exécutable et la vérification stricte du type MIME est activée.

Existe-t-il un moyen de désactiver ce comportement ou existe-t-il un service qui permet de créer des liens vers des fichiers bruts GitHub?

Code de travail:

<script src="bootstrap-wysiwyg.js"></script>

Code non fonctionnel:

<script src="https://raw.github.com/mindmup/bootstrap-wysiwyg/master/bootstrap-wysiwyg.js"></script>

Il existe une bonne solution pour cela, maintenant, en utilisant jsdelivr.net .

Étapes :

1. Trouvez votre lien sur GitHub et cliquez sur la version "Raw".
2. Copiez l'URL.
3. Changement raw.githubusercontent.com parcdn.jsdelivr.net
4. Insérez /gh/avant votre nom d'utilisateur.
5. Retirer le branch nom.
6. (Facultatif) Insérez la version à laquelle vous souhaitez créer un lien, car @version(si vous ne le faites pas, vous obtiendrez la dernière version - ce qui peut entraîner une mise en cache à long terme)

Exemples :

http://raw.githubusercontent.com/<username>/<repo>/<branch>/path/to/file.js

Utilisez cette URL pour obtenir la dernière version:

http://cdn.jsdelivr.net/gh/<username>/<repo>/path/to/file.js

Utilisez cette URL pour obtenir une version spécifique ou valider le hachage:

http://cdn.jsdelivr.net/gh/<username>/<repo>@<version or hash>/path/to/file.js

Pour les environnements de production , pensez à cibler une balise ou un hachage de validation spécifique plutôt que la branche. L'utilisation du dernier lien peut entraîner une mise en cache à long terme du fichier, entraînant la non-mise à jour de votre lien lorsque vous envoyez de nouvelles versions. La liaison à un fichier par commit-hash ou tag rend le lien unique à la version.

Pourquoi est-ce nécessaire?

En 2013, GitHub a commencé à utiliser X-Content-Type-Options: nosniff , ce qui demande aux navigateurs plus modernes d'appliquer la vérification stricte du type MIME. Il retourne ensuite les fichiers bruts dans un type MIME retourné par le serveur, empêchant le navigateur d'utiliser le fichier comme prévu (si le navigateur respecte le paramètre).

Pour plus d'informations sur ce sujet, veuillez vous référer à ce fil de discussion .

Ce n'est plus possible. GitHub a explicitement désactivé le hotlinking JavaScript et les nouvelles versions de navigateurs respectent ce paramètre.

Attention: le support des en-têtes nosniff arrive sur Chrome et Firefox

rawgithub.comredirige vers rawgit.comDonc l'exemple ci-dessus serait maintenant

http://rawgit.com/user/package/master/link.min.js

GitHub Pages est la solution officielle de GitHub à ce problème.

raw.githubusercontentoblige tous les fichiers à utiliser le text/plaintype MIME, même s'il s'agit d'un fichier CSS ou JavaScript. Donc, aller https://raw.githubusercontent.com/‹user›/‹repo›/‹branch›/‹filepath›ne sera pas le type MIME correct, mais un fichier en clair et le lier via <link href="..."/>ou <script src="..."></script>ne fonctionnera pas - le CSS ne s'appliquera pas / le JS ne fonctionnera pas.

GitHub Pages héberge votre dépôt à une URL spéciale, donc tout ce que vous avez à faire est d'archiver vos fichiers et de pousser. Notez que dans la plupart des cas, GitHub Pages vous oblige à vous engager dans une branche spéciale,gh-pages .

Sur votre nouveau site, qui est généralement https://‹user›.github.io/‹repo›, tous les fichiers validés dans la gh-pagesbranche (le commit le plus récent) sont présents à cette URL. Vous pouvez donc créer un lien vers votre fichier js via <script src="https://‹user›.github.io/‹repo›/file.js"></script>, et ce sera le type MIME correct.

Avez-vous des fichiers de construction?

Personnellement, ma recommandation est d'exécuter cette branche parallèlement à master. Sur la gh-pagesbranche, vous pouvez éditer votre .gitignorefichier pour archiver tous les fichiers dist / build dont vous avez besoin pour votre site (par exemple si vous avez des fichiers minifiés / compilés), tout en les ignorant sur votre masterbranche. Ceci est utile car vous ne souhaitez généralement pas suivre les modifications apportées aux fichiers de build dans votre référentiel standard. Chaque fois que vous souhaitez mettre à jour vos fichiers hébergés, fusionner simplement masteren gh-pages, reconstruire, engager, puis pousser.

(protip: vous pouvez fusionner et reconstruire dans le même commit avec ces étapes :)

$ git checkout gh-pages
$ git merge --no-ff --no-commit master  # prepare the merge but don’t commit it (as if there were a merge conflict)
$ npm run build                         # (or whatever your build process is)
$ git add .                             # stage the newly built files
$ git merge --continue                  # commit the merge
$ git push origin gh-pages

Les réponses ci-dessus répondent clairement à la question, mais je veux proposer une autre alternative - Une vision / approche différente pour résoudre le problème similaire.

Vous pouvez également utiliser l'extension de navigateur pour supprimer l'en- X-Content-Type-Optionstête de réponse des raw.githubusercontent.comfichiers. Il existe quelques extensions de navigateur pour modifier les en-têtes de réponse.

1. À la demande: Chrome + Firefox
2. Modifier les en-têtes: Firefox

Si vous utilisez Requestly, je peux suggérer deux solutions

Solution 1: utilisez la règle de modification des en-têtes et supprimez l'en-tête de réponse

Pas

1. Installez Requestly depuis http://www.requestly.in
2. Aller à la page des règles
3. Cliquez sur Ajouter une icône pour créer une règle
4. Sélectionnez Modifier les en-têtes
5. Donnez un nom et un descriptif
6. Sélectionnez Remove-> Response->X-Content-Type-Options
7. Dans le champ Source, entrez Url-> Contains->raw.githubusercontent.com

Solution 2: utiliser la règle de remplacement d'hôte

1. Installez Requestly depuis http://www.requestly.in
2. Aller à la page des règles
3. Cliquez sur Ajouter une icône pour créer une règle
4. Remplacez raw.githubusercontent.comparrawgit.com

Consultez cette capture d'écran pour plus de détails

Comment tester

Nous avons créé un simple JS Fiddle pour tester si nous pouvons utiliser des fichiers github bruts comme scripts dans notre code. Voici le violon avec le code suivant

<center id="msg"></center>

<script src="https://raw.githubusercontent.com/sachinjain024/practicebook/master/web-extensions-master/storage/background.js"></script>
<script>
try {
  if (typeof BG.Methods !== 'undefoned') {
    document.getElementById('msg').innerHTML = 'Script evaluated successfully!';
  }
} catch (e) {
  document.getElementById('msg').innerHTML = 'Problem evaluating script';
}
</script>

Si vous voyez Script evaluated successfully!, cela signifie que vous pouvez utiliser un fichier github brut dans votre code Sinon, cela Problem evaluating scriptindique qu'il y a un problème lors de l'exécution du script à partir de la source github brute.

J'ai également écrit un article sur le blog Requestly à ce sujet. Veuillez le consulter pour plus de détails.

J'espère que cela aide!!

Avertissement: je suis l'auteur de Requestly afin que vous puissiez blâmer pour tout ce que vous n'aimez pas.

https://raw.githack.com/

trouvé ce site fournir un CDN pour

• supprimer l'en- nosnifftête http
• corriger mime typepar nom ext

et ce site:

https://rawgit.com/

REMARQUE: RawGit a atteint la fin de sa durée de vie utile

Pour que les choses soient claires et courtes

//raw.githubusercontent.com -> //rawgit.com

Notez que cela est géré par l'hébergement de développement de rawgit et non par leur cdn pour l'hébergement de production

Mon cas d'utilisation était de charger directement des ` ` bookmarklets '' depuis mon compte Bitbucket qui a les mêmes restrictions que Github. Le travail autour de moi est venu à AJAX pour le script et exécuté evalsur la chaîne de réponse, l'extrait ci-dessous est basé sur cette approche.

<script>
    var sScriptURL ='<script-URL-here>'; 
    var oReq = new XMLHttpRequest(); 
    oReq.addEventListener("load", 
       function fLoad() {eval(this.responseText + '\r\n//# sourceURL=' + sScriptURL)}); 
    oReq.open("GET", sScriptURL); oReq.send(); false;
</script>

Notez que l'ajout d'un sourceURLcommentaire permet de déboguer le script dans les outils de développement du navigateur.

Lorsqu'un fichier est téléchargé sur github, vous pouvez l'utiliser comme source externe ou hébergement gratuit. Troy Alford l'a expliqué bien ci-dessus. Mais pour vous faciliter la tâche, permettez-moi de vous expliquer quelques étapes simples, alors vous pouvez utiliser un fichier brut github dans votre site:

Voici le lien de votre fichier:

https://raw.githubusercontent.com/mindmup/bootstrap-wysiwyg/master/bootstrap-wysiwyg.js

Maintenant, pour l'exécuter, vous devez supprimer https: // et le point (.) Entre raw et githubusercontent

Comme ça:

rawgithubusercontent.com/mindmup/bootstrap-wysiwyg/master/bootstrap-wysiwyg.js

Maintenant, lorsque vous visiterez ce lien, vous obtiendrez un lien qui peut être utilisé pour appeler votre javascript:

Voici le lien final:

https://rawgit.com/mindmup/bootstrap-wysiwyg/master/bootstrap-wysiwyg.js

De même, si vous hébergez un fichier css, vous devez le faire comme mentionné ci-dessus. C'est le moyen le plus simple d'obtenir un lien simple pour appeler votre fichier css ou javascript externe hébergé sur github.

J'espère que ceci est utile.

URL de référence: http://101helper.blogspot.com/2015/11/store-blogger-codes-on-github-boost-blogger-speed.html

J'ai trouvé que l'erreur était due aux commentaires au début du fichier, vous pouvez résoudre ce problème, en créant simplement votre propre fichier sans commentaire et en poussant vers git, il ne montre aucune erreur

Pour preuve, vous pouvez essayer ces deux fichiers avec le même code de pagination facile:

sans commentaire

avec commentaire

J'ai eu le même problème que vous, j'ai changé pour

<script type="application/javascript" src="bootstrap-wysiwyg.js"></script>

Ça marche pour moi.

Le moyen le plus simple:
<script type="text/plain" src="http://raw.githubusercontent.com/user/repo/branch/file.js"></script>
servi par GitHub,
et

très

raw.github.comn'est pas vraiment un accès brut à un fichier, mais une vue rendue par Rails. L'accès raw.github.comest donc beaucoup plus lourd que nécessaire. Je ne sais pas pourquoi raw.github.comest implémenté en tant que vue Rails. Au lieu de résoudre ce problème de route, GitHub a ajouté un en- X-Content-Type-Options: nosnifftête.

Solution de contournement:

• Mettez le script dans user.github.io/repo
• Utilisez un CDN tiers comme rawgit.com.

Alternativement, si vous générez votre balisage côté serveur, vous pouvez simplement récupérer et injecter. Par exemple, dans JSTL, vous pouvez faire ceci:

<script type="text/javascript">
    <c:import url="https://raw.github.com/mindmup/bootstrap-wysiwyg/master/bootstrap-wysiwyg.js" />
</script>

Ils n'autorisent pas le hotlinking pour une raison, donc probablement une mauvaise forme si vous voulez être un bon citoyen. Je vous suggère de mettre en cache ce javascript et de ne le récupérer que périodiquement comme bon vous semble.

Exemple

original

https://raw.githubusercontent.com/antelove19/qrcodejs/master/qrcode.min.js

cdn.jsdelivr.net

https://cdn.jsdelivr.net/gh/antelove19/qrcodejs/qrcode.min.js