Една и съща политика за произход, google chrome, canvas и file:// схема

Когато се опитва да прочете данни за изображение от платно, върху което предварително е нарисувано изображение, Google Chrome повдига кръстосано изключение (оплаква се, че платното е „опетнено“). Структурата на директорията е следната.

/html/base/path
|-- index.html         contains the canvas element, references the script.js
|-- script.js          loads imgs/images.jpg, paints and queries the canvas
`-- imgs/image.jpg

Грешката възниква само когато страницата е заредена от схемата file://.

Чудя се дали това е грешка в Chrome. Ако не, кои правила се прилагат? Има ли заобиколни решения?

За съжаление офлайн гледането е най-добрият случай за употреба, така че

  • схемата file:// е незаменима
  • няма контрол върху настройките на браузъра в целевата система.

person wnrph    schedule 25.09.2012    source източник
comment
MDN за това: developer.mozilla.org/en-US/docs/   -  person m90    schedule 25.09.2012
comment
Благодаря @m90. Колкото и да е странно, правилото, посочено в MDN, изрично позволява горната процедура: файл може да чете друг файл само ако родителската директория на първоначалния файл е предшестваща директория на целевия файл   -  person wnrph    schedule 25.09.2012
comment
Също така силно свързано: stackoverflow.com/questions/3481977/is-there-a-way-to-bypass-javascript-jquerys-same-origin-policy-for-local-acce   -  person m90    schedule 25.09.2012
comment
@m90 Няма ajax, не getjson няма външен url. Връзката не ми се струва толкова силна, но благодаря!   -  person wnrph    schedule 25.09.2012


Отговори (3)


Файловете, заредени с file://, винаги се считат за идващи от различни домейни, това е функция, която не можете да заобиколите.

От дефиницията за произход на HTML5 спецификацията:

Ако документ е получен по някакъв друг начин (напр. данни: URL адрес, въведен от потребителя, документ, създаден с помощта на API createDocument() и т.н.), произходът е глобален уникален идентификатор, присвоен при създаването на документа.

Можете да показвате, но не можете да анализирате или променяте данни, прочетени от друг файл, ако протоколът за зареждане е file:.


Какво аз вероятно бих направил във вашата ситуация (ако го разбирам правилно от вашите коментари): Бих написал малка програма, която може да бъде пусната във външния носител за съхранение, която и двете ще стартират http сървър и стартирайте уеб браузър. Аз бих го направил в Go (просто е да се направи http сървър в два или три реда, собствена компилация за linux, Mac и Windows, което ви позволява да предоставите всички необходими изпълними файлове), но могат да се използват и други езици .

person Denys Séguret    schedule 25.09.2012
comment
защо е така Това бъг ли е? Ако не: кои правила се прилагат? - person wnrph; 25.09.2012
comment
Това е функция. Но какво имате предвид под офлайн гледане? Ако става въпрос за файлове, изтеглени от същия домейн, може да имате други решения, свързани с HTML5 кеша. Но ако искате да имате достъп до потребителски файлове, не можете. - person Denys Séguret; 25.09.2012
comment
Преглед офлайн от физически носители за съхранение (като писалки, компактдискове и др.) - person wnrph; 25.09.2012
comment
Така че вероятно нямате късмет. Други решения (може би аплети) също биха включвали известен контрол на браузъра. - person Denys Séguret; 25.09.2012
comment
Веднъж трябваше да намеря уебсайт на флаш устройство, заредя swf файл чрез swfobject (здравей политика за същия произход). В крайна сметка стартирах XAMPP от файла за автоматично стартиране, когато устройството беше монтирано. Доста грозно, но това беше единственото решение, което можех да намеря. - person m90; 25.09.2012
comment
@dystroy Благодаря за връзката w3c. Засега не звучи толкова зле. Ако има начин да направите данните за изображението CORS-same-origin (каквото и да означава това), произходът на изображението ще бъде документът. Това означава ли, че мога да чета данните му? - person wnrph; 25.09.2012
comment
Единственият начин, който знам, за да уточня CORS оторизации, е да използвам HTTP заглавки. Но може би има и друго решение. - person Denys Séguret; 25.09.2012
comment
Благодаря дотук. Ще се опитам да разбера този том. - person wnrph; 25.09.2012
comment
Този отговор е правилен, но трябва да се отбележи, че текущите изисквания за определяне на произхода на URL адрес с file:-протокол са в стандарта за URL адрес на url.spec.whatwg.org/#origin: „Колкото и да е жалко, това е оставено като упражнение за читателя. Когато се съмнявате, върнете нов непрозрачен произход.“ — с други думи, зависи от внедряването (тъй като „четецът“, към когото се обръща спецификацията, е внедрителят на браузъра) – но на практика повечето браузъри вече третират всеки file: URL като от нов уникален произход, който не съвпада с произхода на никой друг file: URL. - person sideshowbarker; 02.12.2019
comment
Вижте също groups.google.com/a/ chromium.org/forum/#!topic/blink-dev/ - person sideshowbarker; 02.12.2019
comment
Трябва също да се отбележи, че спецификацията, която е публикувана на w3.org/TR/html5 спецификацията вече е остаряла. Всъщност този URL адрес сега просто пренасочва към WHATWG HTML стандарта (защото го промених на пренасочване преди няколко месеца). Всъщност всички HTML спецификации, публикувани в дървото w3.org/TR, вече са остарели, както и в общи почти спецификации, публикувани в дървото w3.org/TR. Така че, когато цитирате спецификации за текущите изисквания на браузъра, трябва да се използват или спецификациите на WHATWG, или спецификации с https://w3c.github.io/ URL адреси (актуални/активно поддържани „чернови на редактора“). - person sideshowbarker; 02.12.2019

Дайте им инструкции да стартират chrome с флага --allow-file-access-from-files.

Освен това, те ще трябва да стартират екземпляр на локален сървър, за да избегнат грешките.

person epascarello    schedule 25.09.2012
comment
От OP: няма контрол върху настройките на браузъра в целевата система (но може би OP ще трябва да промени изискванията си). - person Denys Séguret; 25.09.2012
comment
@dystroy :-) за съжаление не е мое собствено изискване - person wnrph; 25.09.2012

На практика това е нова политика за сигурност на Chromium. Не можете да направите нищо, освен да деактивирате тази политика, както е посочено по-горе от epascarello. Тази бъг със звезда, те искаха да разхлабят това правило.

Вижте и този отговор.

person kinORnirvana    schedule 20.10.2013