CacheBust in dojoConfig bricht Pfade

Question

ich das gleiche Problem someone reported a year ago on ESRI forum haben: die Abfrage-String erscheint vor dem Dateinamen, kurz nach dem letzten Schrägstrich, wie folgt aus:

http://js.arcgis.com/3.13/esri/images/symbol/sfs/?1430314495556diagonalcross.png 

Für mich ist es das gleiche, außer für meine cacheBust bricht nicht .png Bilder, aber manifest.json Dateien (aber nicht config.json). Scheint, dass irgendwo ein Wechsel von unterstützten Erweiterungen/Dateinamen mit "Regel zum Hinzufügen von Abfragezeichenfolgen nach dem letzten Schrägstrich" als Standard erfolgt. Das Hinzufügen einer Abfragezeichenfolge nach dem Dateinamen half nicht - Dojo fügte eine weitere Abfragezeichenfolge hinzu, wo dies nicht sein sollte.

Wenn dies wirklich durch eine unsensible Whitelist verursacht wird, muss ich es finden und ändern. Ich überprüfte den Web AppBuilder (Version 1.4) und fand keine Erwähnung der cacheBust. Ein anderer möglicher Täter ist die ArcGIS-JavaScript-API (3,15 in meinem Fall) - sie enthält eine Referenz für cacheBust in Zeile 11 in ihrer verschleierten init.js, aber ich habe es nicht geschafft, die Stelle zu verfolgen, wo die Abfragezeichenfolge an die URL platziert wird. Der Fehler in Dojo selbst (1.10) scheint unwahrscheinlich, aber es scheint immer noch möglich.

Gibt es eine Lösung? Die Verwendung von heruntergeladenem Code für die API ist in Ordnung. Wenn nicht, kann mir jemand helfen, den richtigen Platz im Code zu finden, oder widerlegen, dass das Problem dort ist?

Answer 1

Ich habe die API heruntergeladen, ein wenig angeschaut und festgestellt, dass es keine restriktive Whitelist gibt. Der Querystring wird nur zu früh einer Basis-URL zugewiesen, zu der die Dateinamen später hinzugefügt werden. Also wäre die Lösung zu finden, wo die Dateinamen hinzugefügt werden und diesen Prozess querystring-bewusst machen. So

Ich fand, wo die manifest.json zugewiesen wurde (im Web AppBuilder, Datei WidgetManager) und änderte den Abfragezeichenfolgeflag zu handhaben:

if (widgetJson.folderUrl.indexOf("?") > -1) { 
    url = widgetJson.folderUrl.substr(0, widgetJson.folderUrl.indexOf("?")) + 'manifest.json' + widgetJson.folderUrl.substr(widgetJson.folderUrl.indexOf("?")); 
} else { 
    //this is how it looked before 
    url = widgetJson.folderUrl + 'manifest.json'; 
} 

Der Code könnte etwas mehr elegant sein, aber es funktioniert. Es gab einige andere Dateien, die von cacheBust entstellt wurden, aber dieser Algorithmus funktionierte.

Answer 2

Ich habe einige in den Code überprüft, wie in einer anderen Antwort erwähnt:

if (widgetJson.folderUrl.indexOf("?") > -1) { 
    url = widgetJson.folderUrl.substr(0, widgetJson.folderUrl.indexOf("?")) + 'manifest.json' + widgetJson.folderUrl.substr(widgetJson.folderUrl.indexOf("?")); 
} else { 
    //this is how it looked before 
    url = widgetJson.folderUrl + 'manifest.json'; 
} 

Ich weiß nicht, diesen Ansatz empfehlen. Ich benutze v2.3.

Der Code zur Bestimmung der zu verwendenden URL unterscheidet sich in den 3d- und 2d-Abschnitten des Produkts. Dieser Code behebt nur das URL-Problem mit manifest.json-Dateien. Es behebt nicht das gleiche Problem mit den Symboldateien (oder möglicherweise anderen Dateitypen).

Wenn Sie den Web Appbuilder-Anwendungscode ändern, wird er außerdem in jede neu erstellte Anwendung kopiert. Umgekehrt müssen Sie, wenn Sie bereits eine Anwendung erstellt haben, die Änderung einmal pro vorhandener Anwendung erneut vornehmen. Jedes neue Dateityp-Problem, das auftritt, verursacht eine weitere Fehlerbehebung pro Web-Appbuilder-Produktinstallation und pro Anwendung, die damit erstellt wird. Bei jedem neuen Upgrade von Esri müssen möglicherweise genau die gleichen Änderungen vorgenommen werden.

Ich würde empfehlen, CacheBust nicht auf True zu setzen, bis Esri das zugrundeliegende Code-Problem behebt, anstatt zu versuchen, dies zu patchen.