Angular.js: encodeUriSegment in Ressourcen codiert Parameter, sollte optional sein

Erstellt einen Gist mit den Änderungen für das Hijacking :) https://gist.github.com/3749345

+1 dazu. Bietet mehr Flexibilität. In unserem Anwendungsfall verwenden wir Spring Data Rest für das Backend und Suchmethoden sind Pfadparameter, die wir Aktionen zuordnen müssen, idealerweise im selben Ressourcenobjekt wie für die grundlegenden CRUD-Operationen.

+1. Unsere IDs enthalten Schrägstriche (wir verwenden RavenDB) und es wäre eine saubere Lösung, wenn es nicht verschlüsselt wäre

Es ist in Ordnung, es optional zu machen, aber stellen Sie bitte sicher, dass es standardmäßig aktiviert ist.

Es ist nicht ratsam, URIs nicht zu codieren. Dies nicht zu tun, mag jetzt "sauber" erscheinen, aber ich versichere Ihnen, dass es Sie in diesem oder im nächsten Leben in den Arsch beißen wird.

Wenn ich http://www.ietf.org/rfc/rfc3986.txt richtig gelesen habe, sollte uns der unverschlüsselte Schrägstrich für das Fragment erlaubt sein.

3.5. Fragment

Die Fragment-ID-Komponente eines URI ermöglicht indirekte
Identifizierung einer sekundären Ressource durch Bezugnahme auf eine primäre
Ressource und zusätzliche identifizierende Informationen. Das Identifizierte
sekundäre Ressource kann ein Teil oder eine Teilmenge der primären Ressource sein
Ressource, einige Ansichten über Darstellungen der primären Ressource, oder
eine andere Ressource, die durch diese Darstellungen definiert oder beschrieben wird. EIN
Fragmentidentifiziererkomponente wird durch das Vorhandensein von a angezeigt
Nummernzeichen ("#") und mit dem Ende des URI abgeschlossen.

 fragment    = *( pchar / "/" / "?" )

...
Die Zeichen Schrägstrich ("/") und Fragezeichen ("?") sind erlaubt
stellen Daten innerhalb der Fragmentkennung dar. Passen Sie auf, dass einige
ältere, fehlerhafte Implementierungen verarbeiten diese Daten möglicherweise nicht korrekt
wenn es als Basis-URI für relative Referenzen verwendet wird (Abschnitt
5.1).

Anwendungsfall: $location.hash('/secondary-resource')

Ich bin nur neugierig, ist es möglich, dieses Problem zu vermeiden, indem Sie Ihre Parameter doppelt codieren?

Sorry, das macht es dann noch schlimmer. Nur um zu bestätigen, dass ich eine Reihe von Öffnungen ausprobiert habe, obwohl es sich sinnlos anfühlte!

'/', '%252F' --> %25252F

Ebenfalls,

/ %2f --> %252F
'/', '//' --> %2F%2F

Danke für den Gedanken. Anfrage steht noch.

Heute darauf gestoßen. +1
Ich mag es vielleicht nicht, aber unsere IDs enthalten auch Schrägstriche. Dies muss optional sein.

+1

+1

+1

+1

+1

+1

Ich sehe die Erwähnung einer Datenbank (RavenDB), die die aktuelle Implementierung problematisch macht, aber ich würde erwarten, dass es einen zwischengeschalteten Server gibt, der verschlüsselte Komponenten erwartet und sie mit der richtigen ID im Backend decodiert. Könnte jemand einen konkreteren Anwendungsfall dafür liefern, wo die erzwungene Codierung Probleme verursacht (sorry, ich habe nicht mehr Kontext zu RavenDB)?

Wir zögern, dies beim aktuellen Design von $resource zuzulassen, weil es Benutzereingaben zu einfach machen würde, den Pfad einer Anfrage zu beeinflussen.

Ich verwende $location für ein REST/Hypermedia-Design und nicht RavenDB (oder $resource). Ich musste mit einer gepatchten Version der Bibliothek arbeiten.

Ich suche auch nach einer Bestätigung, dass dieser Vorschlag tatsächlich auch dem RFC folgt – siehe meinen Kommentar oben

Ich bin vielleicht auch ein bisschen eingerostet in der Bibliothek - also große Entschuldigung, wenn ich falsch liege - es gibt auch zwei Implementierungen von einer in Ressource bei L332 und einer in Angular bei 1071 .

Ich brauche nur die in Angular, weil sie von $location verwendet wird ;-) (ja, ich sehe das Problem hier, also würde ich nicht vorschlagen, keine anderen Implementierungen zu haben). Entschuldigung, wenn ich eine falsche Analyse habe.

+1
Hat jemand eine Problemumgehung zum Erstellen von Ressourcen-URLs mit Schrägstrichen?

Gemäß der oben erwähnten Patchzeile in den Dateien werden die beiden ebenfalls oben erwähnten Implementierungen . Es ist nervtötend.

Gibt es diesbezüglich Bewegung?
Fügen Sie einfach einen Punkt hinzu, an dem ich selbst eine solche Option wirklich gebrauchen könnte.

Sie da,

Ich habe das gleiche Problem, aber das Wesentliche funktioniert bei mir nicht. Wo muss ich diese encodeUirSegment-Methode platzieren oder wo kann ich diese Option platzieren? :/

Ich habe einen HTTP-Interceptor verwendet, um URLs umzuwandeln. Es funktionierte, bis ich es auf IE11 getestet habe. Winkelunterbrechungen bei XHR-Anforderungen an URLs einschließlich % in IE11. Bei IE10 bin ich mir nicht sicher. Angular soll IE9+ unterstützen ( Referenz )

Ich schätze, ich gehe zurück zum modifizierten ngResource.

@connorbode --- Alter, wie es in Ihrem Problem erwähnt wurde, schreiben Sie einen fehlgeschlagenen Testfall =) Dieser Pfad SOLLTE bereits abgedeckt sein, also gibt es zwei Möglichkeiten, entweder ist er nicht abgedeckt und sollte es sein, oder Sie tun etwas, um zu brechen Dies.

Lassen Sie uns herausfinden, welche es ist!

+1

+1

+1

Unmöglich, mit CouchDB und Design-Dokumenten zu arbeiten (_design/cafehub/_view/menu_items)

Könnt ihr meiner Pull-Anfrage statt diesem Problem +1 geben? Es behebt das Problem, wurde jedoch seit seiner Einreichung im Allgemeinen ignoriert. https://github.com/angular/angular.js/pull/7940

+1
Benötigen Sie dies wirklich, um mit einigen Legacy-Webdiensten zu interagieren, die keine URL-Decodierung durchführen

+1

Es gibt definitiv praktikable, nützliche Umstände, in denen ein Benutzer die Codierung von URL-Parametern deaktivieren möchte (z. B. wenn Sie an eine Basis-URL einen Pfad zu einer Ressource anhängen möchten).

+1

+1

+1

+1

@toddb nur zu Ihrer Information, Ihr Spezifikationszitat bezieht sich auf den Fragmentteil einer URL, dh den Teil #foo/bar , bei dem das Entkommen eines Schrägstrichs tatsächlich nicht erforderlich oder angemessen ist. Bei diesem Fehler geht es jedoch darum, einen Schrägstrich im Hauptpfadteil der URL zu maskieren. Im Allgemeinen glaube ich nicht, dass der RFC darauf zutrifft, wie der $resource-Dienst von Angular mit dem Musterabgleich und der URL-Konstruktion umgeht, betrifft den RFC wirklich nicht viel.

Schrägstriche in einem regulären :param -Stilparameter nicht zu maskieren, hat das Problem, dass das Muster dadurch nicht invertierbar wird. Wenn Sie beispielsweise /x/:param haben und die Generierung /x/y/z für {param: 'y/z'} zulassen, wird das resultierende /x/y/z nicht mit dem URL-Muster analysiert.

IMHO könnte es sinnvoll sein, eine Funktion in URL-Mustern zu haben, um ein Sternmuster zu akzeptieren, das Schrägstriche frisst, z. B. "/:param1/:param2/*pathParam" , wo *pathParam Schrägstriche in der URL fressen würde. Für * -Parameter wäre es dann sinnvoll, auch Schrägstriche zu akzeptieren, ohne sie zu maskieren.

@mprobst - Sie haben ganz recht, dass ich einen Fehler nur um das Fragment herum protokolliert habe. Der Code, wie ich ihn verwende, wirkt sich _auch_ auf das Fragment aus. Ich verwende nicht den Dienst $resource , sondern $location . Wenn ich mich recht erinnere, gibt es ein paar Implementierungen des uriSegment-Codes.

Der Patch von @connorbode aus einer schnellen Lektüre wird das Problem beheben. Beifall

+1

+1

+1

+1

+1

+1

+1

+1

Sie können die gleiche Syntax wie in der ui-router lib verwenden:
http://angular-ui.github.io/ui-router/site/#/api/ui.router.util.type :UrlMatcher

+1

es passiert auch vor Ort

:+1:

+1

Ich mache gerade eine Dekodierung, um meine ursprüngliche URL an das Backend zu senden

.factory('decodeUriSegment', () => {
    return (url) => {
      return url.replace(/@/g, '%40')
        .replace(/:/g, '%3A')
        .replace(/\$/g, '%24')
        .replace(/,/g, '%2C')
        .replace(/\+/g, '%20');
    };
  });

+1

+1

app.config(function($resourceProvider) {
    $resourceProvider.defaults.stripTrailingSlashes = false;
});

https://github.com/angular/angular.js/pull/5560

+1

Ich erhalte diesen Fehler im Angularjs-$-Ressourcendienst
Fehler: encodeUriSegment ist keine Funktion

@ibrahim89 , stellen Sie sicher, dass Sie dieselbe Version von angle und angle-resource verwenden.

@gkalpak , danke!!

mein Fehler ist gelöst