Globales Jquery, threading, o.ä.

[selig]

N'abend zusammen,

ich habe eine (vll auch zwei) Fragen

1. Gibt es irgendeine Lösung wie ich z.B. auf Seite eins (upload.html) einen Upload mit Jquery/Ajax starten kann (soweit kein problem) und während der Upload im Hintergrund weiterläuft, auf Seite 2, 3, 4 wechseln kann,... mit wegen mir einem Alert auf der Seite auf welcher ich mich gerade befinde, sobald der Upload fertig ist?!

if(1. == true)...

2. Wie nennt sich das, wie mach ich das, wo finde ich was dazu?!


Vielen Dank schonmal

Grüße selig

 

[Fluffy]

Was du suchst nennt sich Shared Webworker

HTML Standard

Ich weiss aber nicht wie es um den Support bestellt ist.
javascript - Do Shared Web Workers persist across a single page reload, link navigation - Stack Overflow

Cheers

Fluffy

 

[selig]

Vielen Dank Fluffy

darüber find ich jetzt mehr bei Google zum Thema, das hat mir wirklich weiter geholfen

mal gucken ob ich sowas hinbekomme

Edit:

Der Support für Webworker sieht so aus:

Der Support für SharedWorker leider so:

trotzdem danke


Ty

selig

 

[Fluffy]

NP.
Je nachdem wie deine Anwendung aufgebaut ist kannst du, zumindest bei einer umstrukturierung in eine Single-Page-Application, dein Problem lösen, weil du keinen Shared Webworker brauchst, da deine Seite sich niemals neu lädt, sondern nur das HTML ausgetauscht wird.
Gruß

Fluffy

 

[selig]

Hey Hey,

mit diesem Gedanken hab ich auch schon gespielt, aber dafür ist die Seite nun doch etwas zu umfangreich denke ich... Das letzte Mal, als ich ne Browser-History anlegen wollte, war das ziemlich aufwändig (was ich so in Erinnerung habe )

Was ich mir noch vorstellen könnte wäre, das ganze über Websocks umzusetzen Nur die Frage ob das "shared" ist, oder nicht...

hast du damit schon Erfahrungen gemacht?

Wenn ja: Ich habe einen Bereich auf der Homepage auf dem man eingeloggt sein muss (das verwirkliche ich mit PHP Sessions, damit kann ich dann auch sehen um welchen User es sich handelt). Kann ich wenn ich via WebSocks und einem Python-Server arbeite, irgendwie mit Python auf die Sessions zugreifen?

 

[Fluffy]

Du willst solche Sessions nicht teilen.
Was du willst ist einen Token, der an den Pythonserver übergeben wird.
Dieser wird dann den Token beim Webserver verifizieren und die Daten die über die Verbindung reinkommen verwalten im mittels Push den Webserver verständigen, wenn die Operation abgeschlossen ist.

Wenn du den Server schreibst kannst du aber auch darüber nachdenken das alles mittels Ratchet umzusetzten. Das ist eine von 2 PHP-Websocket-Implementierungen.
Kannst dann die gleiche Codebasis wie die Webseite mitverwenden.
Aber du kannst Ratchet nicht im Webserverkontext laufen lassen, da Ratchet nicht zurückkehrt, und die Runtime einfach behält .
Hier werden dann auch Racekonditions zwischen den 2 Applikationen wieder ganz interessant.

Wie dem auch sei: Websockets sind nicht shared, macht ja auch keinen Sinn, wenn die Funktionalität schon durch Webworker gegeben ist, abgesehen davon ist ein Websocket der Shared ist nutzlos, denn es ist nur ein Verbindungsendpunkt wo die verwaltende Logik einen Ladeprozess der Seite nicht überleben würde.

//edit:
Browserhistorie anlegen ist eigentlich super einfach.
Jede URL die mit einem # endet erzeugt keinen neuen Pageload(es sei den erzwungen), die HTML5-API erlaubt das manipulieren der Historie und Frameworks wie AngularJS machen das schon fast automatisch.

 

[selig]

Okay, ich hoffe ich versteh das jetzt richtig:

ich stelle mit js einen WebSocket zu meinem Pythonserver her,
schicke diesem einen Token? und mein Pythonserver frägt wo genau nach?

Was für einen Token, woher kennt mein JS-Client(Browser des Users) diesen Token, und theoretisch wäre dieser doch ziemlich leicht zu manipulieren?

Um das ganze mal etwas zu erklären, hier ein Beispiel:
Ich habe eine Datenbank mit verschiedenen Usern, die unterschiedlichen Gruppen zugeordnet sind... jede Gruppe hat individuellen Inhalt auf der Seite, auf welchem die User zusammen arbeiten (Texte verfassen, uvm).
Nun muss der Pythonserver aber wissen, welcher User gerade die Verbindung aufgebaut hat, und ob dieser auf der HP eingeloggt ist - damit er über die UserID in der DB die GruppenID suchen kann, um die richtigen Inhalte ausgeben zu können



Das mit der Historie klingt wirklich etwas leichter, als zu dem Zeitpunkt, als ich damit zu tun hatte

Werde ich evtl mal in ein künftiges Projekt einfließen lassen

 

[Fluffy]

Du erstellst mit jeder Session einen Token.
Oder wenn du es sicherer machen willst, bietest du eine API an welche einen Token generiert.
Diese API liefert den Token nur aus wenn die Session gültig ist.
Der Client weiss nun den Token.
Er schickt den Token mit den Daten an Websocketserver.
Dieser fragt dann die Website ob der Token gültig ist.
Bei der Tokengenerierung kannst du dem Token einen Benutzer zuordnen, womit auch die Daten/die Kommunikation mit dem Websocket zugeordnet werden kann.

Gruß

Fluffy

 

[SchwarzeBeere]

Dieser fragt dann die Website ob der Token gültig ist.

Je nach Protokoll (OAuth, OpenID Connect, SAML) kann auch die Webapp das Token parsen, die Signatur sowie die mitgelieferten Atribute prüfen und dann selbst bestimmen, ob das Token gültig ist. D.h. eine Verbindung zur Datenbank ("Identity Provider") ist aus Sicht der WebApp ("Relying Party", bei dir der Pythonserver) nicht mehr notwendig.

 

[Fluffy]

Ja das stimmt.
In dem Fall garantiert die Verschlüsselung das alles valide ist.
Mir geht es aber darum, das es nur eine Instanz gibt die das zu entscheiden hat.
So hast du weniger Code den du pflegen musst.
Sonst baust du 2x den gleichen Code um einen Token zu überprüfen.
Ich sag nur DRY abgesehen davon bekommst du in der Architekturlandschaft schnell wildwuchs wo jedes Project die gleiche Logik separat pflegt weil es keine Schnittstelle gibt die das zentralisiert übernimmt.
Abgesehen davon ist in diesem Anwendungsszenario das Implementieren von OAuth und Co IMHO doch etwas überdimensioniert.

Gruß

Fluffy

 

[SchwarzeBeere]

Ja das stimmt.
In dem Fall garantiert die Verschlüsselung das alles valide ist.
Mir geht es aber darum, das es nur eine Instanz gibt die das zu entscheiden hat.
So hast du weniger Code den du pflegen musst.

Optimalerweise schreibt man eine Library, die das übernimmt, pflegt sie zentral und stellt sie allen Applikationen zur Verfügung. Damit löst du drei Probleme im Vergleich zu einem zentralen Service:
1. Es gibt keinen Single Point of Failure. Zentrale Services neigen dazu auszufallen, Netzwerke können überlastet sein oder zusammen brechen, Firewalls können Pakete droppen. Besteht keine Verbindung zum Service, dann wäre die App nutzlos. Diese Abhängigkeit muss verhindert werden um das Risiko eines Ausfalls zu minimieren.
2. Die Entscheidung eines zentralen Service spielt für die Applikation keine Rolle, solange keine Entschlüsselung (zentraler Entschlüsselungsservice - falsch implementiert ist das die ultimative Sicherheitslücke...) oder ein Tokenaustausch stattfindet (z.B. Security Token gegen Access Token und ID Token bei OpenID Connect).
3. Du steigerst mit einem zentralen Service die Angriffsfläche und gehst unnötige Risiken ein. Einerseits kann die Verbindung mit DDOS gestört werden (Availability), andererseits die TLS Verbindung mittels MITM Angriff abgehört (Confidentiality) oder gar verändert (Integrity) werden, sodass eine Entscheidung nicht 100% als wahr angenommen werden darf, während die Tokenausstellung mit Hilfe von HSMs deutlich sicherer gestaltet werden kann.

Der vierte Vorteil ergibt sich von selbst: Die forcierte Standardisierung ermöglicht die einfache Anbindung von 3rd Party Applikationen.

Abgesehen davon ist in diesem Anwendungsszenario das Implementieren von OAuth und Co IMHO doch etwas überdimensioniert.

OAuth und OpenID sind nicht überdimensioniert. Es gibt für beide Protokolle genügend Libraries und Open Source Projekte, die eine einfache Implementierung ermöglich. SAML ist da natürlich ein anderes Kaliber, da gebe ich dir Recht.

 

[Fluffy]

Ich will nicht das das zu off-topic geht aber, der zentrale Service ist normalerweise nur von dedizierten IP-adressen erreichbar oder liegt idealerweise im Intranet.
(Man hat also so schönen Schnack wie Router, Firewalls IDS, IPS und WAFs dazwischen.)
von daher kann man, vor allem bei mehreren Netzwerkkarten ruhig mal ein bischen das Netzwerk zuspammen, geht trotzdem, und bzgl. der Last, da wird dann halt skaliert, wofür gibt es den Docker und Co? Ist also eher eine Dev-Ops-Frage welche ich nicht auf Code-basis lösen würde.

Eine Library hat den Nachteil das du alle Projekte damit auf eine Programmiersprache festsetzt, nutzt du eine Andere musst du alles nochmal implementieren und willst du verbesserungen machen , muss alles nochmal deployed und getestet werden.

Und hier geht es ja um die zuordnung von Daten wärend einer verifizierten Session, dann kann man auch Schmalhans mal Küchemeister sein lassen, den die Verbindung wird, dem Anwendungsszenario nach niemals ad-hoc aufgebaut sondern immer aus einer vorher validierten Session heraus.
Von daher würde ich hier lieber das KISS-prinzip greifen lassen.

Gruß

Fluffy