2014-01-13 9 views
6

In meiner GAE-Anwendung (Python) habe ich Multitenancy- und Multi-Site-Unterstützung basierend auf dem host-Teil des Anfrageobjekts implementiert.Google App Engine-Channel-API mit benutzerdefinierten Domänen

Zum Beispiel werden www.foo.com/index.html und www.bar.com/index.html beide von der gleichen App behandelt (z. B. myapp.appspot.com). Die App liest den Host-Wert und entscheidet dann, welcher Namespace und welche Site-Konfiguration verwendet werden sollen. Dies funktioniert hervorragend, solange die App die Anfrage direkt vom User-Agent erhält.

Allerdings möchte ich die Channel-API verwenden, aber es gibt ein Problem, weil Anforderungen an /_ah/channel/connected/ und /_ah/channel/disconnected/ nicht vom ursprünglichen Benutzer-Agent stammen. Stattdessen lautet die Anforderung Host: myapp.appspot.com und der Parameter to=myapp.appspot.com. (Der from Parameter ist der Token ich erwarte. Auch www.foo.com/_ah/channel/jsapi zu einem Talkgadget Server umgeleitet wird, die nicht dokumentiert ist, aber scheint, als zu erwarten.)

Ich gehe davon aus, das Problem verursacht durch den Code in channel.js welche nicht Rufen Sie meine App mit dem ursprünglichen Host an, z www.foo.com/_ah/channel/connected. Stattdessen verwendet es einen talkgadget.google.com Host, der (soweit ich das beurteilen kann) dann meine App anruft, aber unter Verwendung von myapp.appspot.com, den ursprünglichen Host ignorierend, und so kann ich den Wert host der Anfrage nicht für meinen Zweck verwenden.

Als Workaround kann ich eine Möglichkeit finden, die Host-Informationen in das Kanal-Token aufzunehmen. Wenn also meine Handler connected und disconnected das Token erhalten, können sie stattdessen das Token verwenden.

Allerdings würde ich gerne wissen, ob es ein besserer Ansatz ist, wo ich immer noch die ursprünglichen Hostnamen (z www.foo.com) Anfragen an /_ah/channel/connected/ und /_ah/channel/disconnected/ bekommen kann. Irgendwelche Ideen?

Dies ist, was ich bisher versucht (mit unkenntlich Erfolg):

den benutzerdefinierten Domain-Host-Namen das JS src-Attribut hinzu:

<script type="text/javascript" src="//www.foo.com/_ah/channel/jsapi"></script> 

ich auch die manuell außer Kraft setzen versucht Basis-uRL des Kanalsockels, schlug hier: https://stackoverflow.com/questions/16558776/google-app-engine-channel-api-same-origin-policy

<script type="text/javascript"> 
onOpened = function() { 
    // TODO 
}; 
onMessage = function() { 
    // TODO 
}; 
onError = function() { 
    // TODO 
}; 
onClose = function() { 
    // TODO 
}; 
goog.appengine.Socket.BASE_URL = "https://www.foo.com/_ah/channel/"; 
channel = new goog.appengine.Channel('{{channelToken}}'); 
socket = channel.open(); 
socket.onopen = onOpened; 
socket.onmessage = onMessage; 
socket.onerror = onError; 
socket.onclose = onClose; 
</script> 

ich konnte keine offizielle Dokumentation für channel.js finden, und ich will nicht etwas implementieren was mit dem nächsten Update von Google leicht zu brechen ist.

+0

Dies funktionierte für mich: 'goog.appengine.Socket.BASE_URL =" https://www.foo.com/_ah/channel/ ";' – Subir

Antwort

1

Kurz von einem Proxy, sehe ich keinen besseren Weg als die In-Band-Informationen. Das Problem ist, dass die Bibliothek/Infrastruktur (kann nicht sicher sein, ohne tiefer zu schauen), die HTTP-Layer-Information (den Host-Header) entfernt, und tatsächlich haben Sie keine Kontrolle über die HTTP-Ebene, um benutzerdefinierte Header zu übergeben Also müssen Sie entweder die Informationen auf einer niedrigeren Ebene haben (TCP bietet hierfür keine Möglichkeit, und da der Einstiegspunkt Ihres Codes über den Browser läuft, der channel.js ausführt, und nicht einen Prozess auf Systemebene läuft auf der nackten Netzwerkschnittstelle, ist dies aus dem Bild entscheidend) oder auf einer höheren Schicht, dh. innerhalb des Kanals.

+1

Sie könnten immer eine Feature-Anfrage in der [Cloud-Plattform Öffentlichkeit Problem-Tracker] (https://code.google.com/p/google-cloud-platform/issues/list). – Nick

+0

Danke, Nick.Ich entschied mich, die Host-Informationen in das Channel-Token zu codieren, damit die Connect/Disconnect-Handler den ursprünglichen Host herausfinden können. Wenn ich jemals auf eine neue Channel-API-Funktion zurückkomme, werde ich wahrscheinlich eine Feature-Anfrage einreichen. Danke für den Link! – Ani

Verwandte Themen