Jump to content

RecService IOS App und ReverseProxy


zerhau

Recommended Posts

zerhau

Guten Abend zusammen, 

 

zunächst hoffe ich, dass alle gut ins neue Jahr gerutscht sind! Frohes Neues Jahr an alle! 
 

Ich habe leider eine eingeschränkten Funktionsumfang beim Betrieb des MediaServers Version 3.0.1 hinter einem Reverse-Proxy festgestellt:
- Die Timeline in der IOS App und beim Zugriff auf die IOS-Seiten über den Browser funktioniert leider nicht. 

- Die Menüelemente Einstellungen und Aufgaben fehlen. 


Der Zugriff aufs Desktop-Web-Interface funktioniert problemlos.

Der Zugriff auf das Mobil-Interface (/IOS) über den Browser funktionieren ebenfalls mit oben genannten Einschränkungen. 

Der Reverse-Proxy ist über einen IIS auf einem Windows Server 2016 realisiert. 
 

Leider kann ich auch nach erfolgter Recherche und zahlreichen Tests keinen Fehler in der Konfiguration des IIS und des MediaServers feststellen, da bei Fehlkonfiguration der gesamte Zugriff ja nicht möglich sein sollte, da LiveTV, EPG-Suche usw. funktionieren. 
Ich würde mich freuen, wenn sich jemand drittes die Screenshots ansieht und sich vielleicht darauf einen Reim machen könnte.

Hat vielleicht jemand ähnliche Einschränkungen festgestellt? 

support.zip kann ich gerne nachreichen, sollte jemand Bedarf haben. 
 

Vielen Dank für eure Hilfe!

 

Stefan

B0CF044F-856B-45DE-805C-81E89B5A2FDD.jpeg

5324A5B1-4CE9-4E2D-A4E1-5C50986D6B6D.jpeg

Link to post
Griga
vor 17 Minuten schrieb zerhau:

Die Menüelemente Einstellungen und Aufgaben fehlen. 

 

Fangen wir erst mal mit denen an. Sie fehlen typischerweise im Mobil-Webinterface, wenn man nur mit Gastrechten auf den Media Server zugreift. Könnte etwas in der Hinsicht vorliegen? Kannst du unter "Timer" neue Timer anlegen (geht nur mit vollen Rechten). Wie sehen deine Einstellungen in den Media Server-Optionen -> Web-Einstellungen aus?

 

Link to post
HaraldL

Vielleicht aus Versehen die "Restricted Version" des DMS statt der "Full Version" aus dem Mitgliederbereich installiert?

 

Link to post
zerhau

Hallo, 


vielen Dank für eure Anregungen und Hilfe, 

ich habe die Full-Version aus dem Mitgliederbereich installiert. 
 

Ich kann über die App einen Timer erstellen. Ich habe eben die Tagesschau von morgen programmiert. 
Die Einstellungen in den Web-Optionen sehen folgendermaßen aus. 
 

Vielen Dank und schöne Grüße.

F6DF92D9-4F09-4AA5-AF91-06EA7CC4EBB2.jpeg

Link to post
Griga

Merkwürdig. Bei Betrieb mit einem Reverse Proxy geht typischerweise etwas schief, wenn der Server absolute statt relative Adressen verwendet. In der HTML-Vorlage für das Menü des Mobil-Webinterface kann ich jedoch nichts in der Art feststellen (siehe DVBViewer-Programmordner\SCVweb\ios\iphone.html oder auch ipad.html für Tablets). Die fehlenden Einträge für Einstellungen und Aufgaben befinden sich zwischen den als Kommentaren getarnten Template-Anweisungen

<!-- START BLOCK : withrights2 -->
.....
<!-- END BLOCK : withrights2 -->

Direkt danach folgt der vorhandene Status-Eintrag, der sich in nichts von den beiden fehlenden unterscheidet.

 

Ich würde mal probeweise die beiden obigen Zeilen komplett rauswerfen, worauf keine vollen Rechte mehr erforderlich sind, und dann schauen, was passiert.

 

Link to post
Griga

P.S. Den Block gibt es zweimal in der iphone.html, sehe ich gerade, einmal mit withrights1 und einmal mit withrights2. Einer ist für das Menü, das sich von rechts ins Bild schiebt, wenn eine andere Seite aktiv ist und man auf das Menü-Icon tippt.

 

Link to post
zerhau
Posted (edited)

Hallo Griga,

 

ich hab die insgesamt 4 Zeilen entfernt. 
Den DMS zur Sicherheit neu gestartet. 
Ich kann keine Änderung feststellen. 
Gleiches Verhalten der App wie zuvor bzgl. den Einträgen. 

6FAE06DF-6DE7-4EB3-8925-7FCFC2F681ED.jpeg
 

im Desktop-Browser sind die Einträge da. 

Edited by zerhau
Link to post
Griga

Wie sieht mit Reverse Proxy die Adresse aus, mit der iphone.html aufgerufen wird? Der Server erwartet darin den Substring "/iphone.html", also mit vorangestelltem Schrägstrich. Wenn er fehlt, wird der Rechte-Block mit den beiden Menüpunkten weggelassen.

 

Bei mir ist die Adresse ohne Reverse Proxy im einfachsten Fall

 

http://localhost:8089/ios/iphone.html

 

Du kannst das Mobil-Webinterface übrigens auch in einem Desktop-Browser unter Windows aufrufen, z.B. Firefox oder Chrome. Es funktioniert dort recht gut, und manches lässt sich so leichter ermitteln, weil man bequemer ein Neuladen erzwingen kann (ohne Cache-Zugriff mit Strg+F5) und die Entwicklerwerkzeuge zur Verfügung stehen.

 

Link to post
zerhau

Hallo Griga, 

 

der Zugriff über die Originaldatei (mit den  vier Zeilen inkludiert) über den Browser funktioniert über den RevProxy problemlos. 
 

Irgendwie is das a bisserl komisch. 
Ich werde nur für heute Schluss machen und mal ne Nacht drüber schlafen. 
 

Vielen Dank schonmal bis hierhin, vielleicht können wir ja die nächsten Tage nochmal weitermachen. 
 

Leider kann ich den Screenshot nicht hochladen. Ich bring die Datei nicht klein genug. Hier nur ein Ausschnitt. 
 

Vielen Dank. 

B300E2C5-0CA9-4AD5-A3D6-B4EA24A0824C.jpeg

Link to post
janee
vor 2 Stunden schrieb Griga:

<!-- START BLOCK : withrights2 --> ..... <!-- END BLOCK : withrights2 -->

Ich habe die beiden Zeilen mal entfernt.

Jetzt sind auch die Menüs : Einstellugen und Aufgaben vorhanden.

 

PS: ich glaube nicht, dass es mit dem ReverseProxy zu tun hat. Ich nutze die App im WLAN

 

Link to post
Griga
vor 7 Stunden schrieb janee:

PS: ich glaube nicht, dass es mit dem ReverseProxy zu tun hat. Ich nutze die App im WLAN

 

Dann schaffe dir mal ein vernünftiges WLAN an :)

 

Scherz beiseite und eine Klarstellung: Ich befasse mich nur mit dem Mobil-Webinterface und eventuellen Problemen damit, wenn es direkt (ohne iOS-App) im Browser aufgerufen wird. Wenn etwas in der iOS-App nicht passt, muss sich der Autor darum kümmern (der das offenbar nicht mehr tut) oder sonstwer, der Lust hat, daran herumzubasteln. Ich habe weder die Zeit noch die erforderliche Apple-Hardware, um das in Ordnung zu bringen.

 

Und jetzt bitte eine Klarstellung von eurer Seite: Treten die beschriebenen Probleme nur mit der App oder auch dem Mobil-Webinterface solo auf?

 

Link to post
janee
vor 4 Stunden schrieb Griga:

Und jetzt bitte eine Klarstellung von eurer Seite: Treten die beschriebenen Probleme nur mit der App oder auch dem Mobil-Webinterface solo auf?

Nur mit der App.

Im Safari und Firefox Browser ist alles in Ordnung.


Ich denke das liegt an der App und sollte von dir nicht weiter verfolgt werden.

Link to post
zerhau
Posted (edited)

Hallo, 

 

ich habe eben noch einen Test gemacht: 

 

Die App greift nicht auf die iphone.html sondern auf die iphone-de.html zu. 

Entfernt man diese Zeilen aus der iphone-de.html, dann tauchen diese beiden Menüs auf und die App funktioniert diesbezüglich. 

<!-- START BLOCK : withrights2 --> ..... <!-- END BLOCK : withrights2 -->

Scheinbar funktioniert hier die Autorisierung mit den in der App separat einzugebenden Credentials nicht zuverlässig. 

Eventuell wäre hier der Programmierer der App gefragt, oder aber man müsste an dieser Stelle das Zusammenspiel der Programme genauer beleuchten. 

 

Bzgl. dem zweiten Punkt hat sich leider das Verhalten nicht geändert. 

Beim Aufruf der Timeline in der App erscheint so etwas wie ein Grundgerüst der Website, die dann die einzelnen Sendungen, Zeiten und Senderlogos beinhaltet. Leider funktionieren hier keinerlei Skripte, die für den Inhalt der Seite verantwortlich sind. Über die App fehlt mir hier allerdings eine bessere Möglichkeit zu debuggen. 

 

Beim Aufruf der IOS -Seiten über einen Browser (Safari (mobile), Edge, Firefox) wird das Grundgerüst der Seite inklusive einiger Sendungen und Senderlogos angezeigt, jedoch sind keinerlei Klicks und keinerlei Aktualisierungen der Seite ausführbar.

 

Hier ein Screenshot aus der App heraus:

(Kann ich leider aufgrund Hochladebeschränkungen nicht hochladen.)

 

Hier noch ein Screenshot aus dem Browser heraus. Leider sind keinerlei Elemente "klickbar".

PNG-Bild3.png.3e366a403cec888688000d3e68d9a2c1.png

 

Leider kann ich den zweiten Screenshot nicht einfügen. Ich kann nur insgesamt 21KB an Anhang hochladen und das reicht leider nicht aus. 

Gibt es hier eine Möglichkeit etwas mehr Hochlademöglichkeit zu bekommen?

 

Vielen Dank. 

 

Schöne Grüße, 

Stefan

Edited by zerhau
Link to post
Griga

Mit der Timeline im Mobil-Webinterface stimmt etwas nicht. Das sehe ich auch unter Windows in Firefox. Wird näher untersucht...

 

  • Thanks 1
Link to post

Ebenfalls funktioniert im "normalen" Webinterface auf Timeline etwas nicht korrekt. Bei dem Aufruf fehlen manchmal die EPG einiger der unteren Programme. Dies ändert sich nach Reload. Manchmal ist dann alles komplett, manchmal fehlen dann aber auch ab einem anderen programmm der EPG.

Ich nutze aktuell Firefox in der aktuellsten Version unter Windows 10.

 

und noch etwas ist mir aufgefallen. Ich habe meine Senderliste in Ordner aufgeteilt, beginnend mit Öffentlich rechtlichen, gefolgt von Privatsendern und dann noch weitere.

Der Fehler tritt bei mir anscheinend nur ab dem 2. Ordner, bei mir Private, auf. Bei dem ersten (Öffentlich Rechtliche) werden immer alle EPG angezeigt.

Edited by jocke
Link to post
Griga
vor einer Stunde schrieb Griga:

Mit der Timeline im Mobil-Webinterface stimmt etwas nicht. Das sehe ich auch unter Windows in Firefox. Wird näher untersucht...

 

Fehlalarm. Bei mir war noch eine experimentelle Version der Datei

 

C:\Program Files (x86)\DVBViewer\SVCweb\ios\js\timeline.js

 

in Verwendung. Mit der aus dem 3.0.x Release ist hier alles in Ordnung, auch auf einem Android Tablet, aber ohne Reverse Proxy.

 

vor einer Stunde schrieb zerhau:

Beim Aufruf der IOS -Seiten über einen Browser (Safari (mobile), Edge, Firefox) wird das Grundgerüst der Seite inklusive einiger Sendungen und Senderlogos angezeigt, jedoch sind keinerlei Klicks und keinerlei Aktualisierungen der Seite ausführbar.

 

Ein Problem dieser Art ist mir bereits vor dem 3.0.0 Release begegnet und wurde dann in der timeline.js behandelt. Es entstand, wenn man vorher im Browser die Dekstop-Timeline verwendet und dort das Datum umgeschaltet hatte. Es verschwand nach einem Neustart des Browsers. Allerdings hatte ich keine Gelegenheit, den Fix unter iOS in Safari zu testen.

 

In solchen Fällen würde ich erst mal ein komplettes Neuladen der Seite erzwingen bzw. Cache und Cookies löschen, um zu sehen, ob sich noch etwas Altes einmischt (sofern du vorher eine DMS Version 2.x verwendet hast). Aber auf diesen neumodischen Telefonen ist das gar nicht so einfach, wie mir berichtet wurde...

 

Vieleicht kann @janee auf seinem iPhone noch mal schauen, wie es mit der timeline.js aus dem Release aussieht. Eventuell kann er dir auch eine alternative Variante zur Verfügung stellen, die er bei der Behandlung des oben erwähnten Problems entwickelt hatte.

 

@jocke Nicht so eine gute Idee, ein weiteres Problem in eine noch nicht abgeschlossenes Thema hineinzuposten. Ich werde das hier nicht behandeln. Starte dafür besser ein separates Thema.

 

Link to post
janee

Versuche zunächst einmal das Webinterface in einem privaten Fenster zu laden. Damit sollte das Cachingproblem umgangen werden. 

Ich schaue mir die Timeline nochmal an.

Link to post
zerhau

Hallo ihr zwei, 

 

ich habe die Mobil-Seite über den iOS Browser sowie über Edge (Desktop) in einem Private-Fenster geladen. 
Die EPG-Einträge sind scroll- aber nicht klickbar. Die Senderlogos werden beim Scrollen nicht mitgescrollt.
Das Datum erscheint mir eher wie ein Textfeld, das editiert werden kann. Das Popup zur Datumsauswahl erscheint nicht. 

Die Links zu „Menü“ und das Side-Menü kann geklickt bzw. eingeblendet werden. Die Buttons „jetzt“, „Abend“, „+“ und „-„ sind nicht klickbar. 

Die Timeline steht auf 5 Uhr. 

Leider kann ich keinen Screenshot hochladen. Die Uploadgrenze ist jetzt bei 297Byte. 
 

 

Schöne Grüße und vielen Dank für eure Hilfe!

Link to post
Griga
vor 25 Minuten schrieb zerhau:

ich habe die Mobil-Seite über den iOS Browser sowie über Edge (Desktop) in einem Private-Fenster geladen. 
Die EPG-Einträge sind scroll- aber nicht klickbar. Die Senderlogos werden beim Scrollen nicht mitgescrollt.

 

Wenn ich das in Edge unter Windows 8.1 nachvollziehen könnte, wäre es einfacher... aber die Mobil-Timeline funktioniert leider wie geschmiert. Im Moment habe ich keine Idee, woran das bei dir liegen könnte - außer am Reverse Proxy. War der dabei im Einsatz? Falls ja, wie sieht es beim Gegentest ohne Reverse Proxy aus?

 

Link to post
janee
vor 24 Minuten schrieb zerhau:

Leider kann ich keinen Screenshot hochladen. Die Uploadgrenze ist jetzt bei 297Byte

Du kannst die alten Anhänge löschen, um wieder etwas hochzuladen.

Dazu musst du oben rechts (3 waagerechte Striche) - Benutzerkonto - meine Dateianhänge klicken.


Du kannst mal den DMS beenden und im DVBViewer Programmverzeichnis den Ordner WebSvc umbenennen. 
Anschließend das DMS Setup erneut ausführen. 
Damit gehen wir sicher, das du den aktuellen Stand des Webinterface auf dem Rechner hast.

Link to post
Griga
vor 31 Minuten schrieb zerhau:

Leider kann ich keinen Screenshot hochladen. Die Uploadgrenze ist jetzt bei 297Byte. 

 Oben rechts im Forum auf deinen Benutzernamen klicken -> Meine Dateianhänge... alte auswählen und löschen.

 

Link to post
zerhau

Hallo zusammen, 

 

vielen Dank für die Hinweise mit den Ahängen, damit kann ich wieder etwas hochladen. 

 

Ich vermute, dass es beim Seitenaufruf mit dem RevProxy ein Pfadproblem gibt. Die IOS Webseite funktioniert ohne Zugriff über den RevProxy ohne Fehler. Die App auch. 

 

In der Debug-Console konnte ich beim Zugriff über Edge folgende "404" Fehler entdecken, der beim Zugriff über den RevProxy auftaucht. Könnt ihr damit etwas anfangen?

 

Fehler.thumb.png.ee3928edfc19ff37897a7f52496d0215.png

 

Hier exemplarisch eine nähere Info zu diesem Fehler: 

 

Fehler2.thumb.png.3f581db1d79477b2270401969522b8af.png

 

Die interaktive Syntaxhighlight / Errorhighlight der Edge-Debug-Konsole beginnt an dieser Stelle und wird dann bis zum Ende dieser Zeile 4 nicht mehr unterbrochen. Anscheinend tritt hier ein Zugriffsproblem mit einer Ressource auf, die nicht auf dem Server gefunden wird. 

 

fehler3.thumb.png.acea3caba0ce19f3932b91d430a2575e.png

 

 

Ich hoffe, ich konnte euch den ein oder anderen Hinweis liefern. 

 

Vielen Dank!

 

Schöne Grüße

 

Link to post
janee

 

vor 24 Minuten schrieb zerhau:

 

 

Fehler.thumb.png.ee3928edfc19ff37897a7f52496d0215.png

 

Fehler 404 bedeutet: nicht gefunden

Ich kann dein Fehlerbild nachstellen, wenn ich die Datei "C:\Program Files (x86)\DVBViewer\SVCweb\lib\jquery.scrollTo-min.js" umbenenne.

Das IOS Webinterface liegt unter "C:\Program Files (x86)\DVBViewer\SVCweb\ios"

Die verwendete js unter "C:\Program Files (x86)\DVBViewer\SVCweb\lib\"

GGfs ist der Reverse Proxy noch nicht richtig konfiguriert (Pfad etc.)

 

Link to post
zerhau

Hallo janee,

 

das habe ich mir auch gedacht, sollten aber einzelne Pfade, die vom aktuellen Pfad abweichen über den Proxy falsch umgeschrieben werden, dann würden allerdings mehrere Dateien und Pfade nicht gefunden werden. (Senderlogos oder ähnliches)
Leider ist das aber in meinen Augen nicht Fall. 

Ich werde mal versuchen, ob ich noch mehr dazu herausfinden kann. 
 

Was macht denn diese Datei genau?

 

Schöne Grüße 

Link to post
janee
vor 24 Minuten schrieb zerhau:

das habe ich mir auch gedacht, sollten aber einzelne Pfade, die vom aktuellen Pfad abweichen über den Proxy falsch umgeschrieben werden, dann würden allerdings mehrere Dateien und Pfade nicht gefunden werden. (Senderlogos oder ähnliches)

Sendelogos werden vom DMS hineingepatched, wenn ich mich recht entsinne. Es wird z.B. auch die jquery-cookie.js nicht gefunden.

Die jquery.js scheint er zu finden. 

 

Das Problem scheint folgendes zu sein:

Ich sehe bei http://xxx/lib/jquery.scrollTo-min.js?_=1609711789659

Den Fett markierten Teil scheint der Proxy nicht zu mögen. Hier muss wohl der Filter angepasst werden?!?

 

Link to post
Griga
vor 7 Stunden schrieb janee:

Es wird z.B. auch die jquery-cookie.js nicht gefunden.

 

Die ist aktuell nicht mehr dabei. Ich habe sie seit dem DMS 3.0 durch

 

C:\Program Files (x86)\DVBViewer \SVCweb\lib\jquery.cookie_2.js

 

ersetzt. Die Datei musste aktualisiert werden, weil Browser zunehmend das samesite Attribut bei Cookies verlangen.

 

vor 7 Stunden schrieb janee:

Ich sehe bei http://xxx/lib/jquery.scrollTo-min.js?_=1609711789659

 

https://stackoverflow.com/questions/2749560/why-does-jquery-ajax-add-a-parameter-to-the-url

 

Vielleicht hilft das weiter. Es hat mit Caching zu tun. Man muss damit rechnen, das Proxies auch cachen.

 

Link to post
zerhau
Posted (edited)

Hallo, 

 

ich habe festgestellt, dass der aufgerufene Pfad wohl falsch sein muss. 

 

Folgendes ist mir aufgefallen:

Wenn ich mir die obigen Screenshots nochmal anschauen, dann werden die Dateien unter 

 

https://<mypublicdomain>/lib/jquery.scrollTo-min.js?_=1609705973217

 

die Pfade müssen aber

https://<mypublicdomain>/recservice/lib/jquery.js... lauten

 

Ich habe dazu weiter recherchiert und mir ist aufgefallen, dass die ios.js Datei eine relative Pfadebene zu weit oben nach der jquery.js sucht. 

Ich habe nun über meinen Proxy diese /lib/ ebene weiter oben umgeschrieben und konnte den Fehler dadurch beseitigen. Diese Lösung ist aber meiner Meinung nach unbefriedigend, da andere Zugriffe dadurch gestört werden könnten.

 

Ich habe deshalb in der ios.js Zeile 934 und 935 folgendermaßen geändert: 

 

    $.getScript('../lib/jquery.scrollTo-min.js'),
    $.getScript('../lib/jquery.cookie_2.js'),

Ursprünglich: 

    $.getScript('../../lib/jquery.scrollTo-min.js'),
    $.getScript('../../lib/jquery.cookie_2.js'),

 

Diesen Sprung habe ich um eine relative Ebene verkürzt und jetzt funktioniert die Seite problemlos und ohne weitere Proxy Änderung. 

 

Könnt ihr diese Lösung bitte prüfen und verifizieren?!?

 

Leider sehe ich diese Änderung momentan nur im Edge / Firefox und noch nicht in der App. Das schiebe ich aber momentan noch auf den Cache. Ich werde die Lösung auf jeden Fall mal so stehen lassen und weiter beobachten. 

Weiß jemand zufällig, wie man den Cache der RecService App löscht?

Edited by zerhau
Rechtschreibfehler
Link to post
Griga
vor 2 Stunden schrieb zerhau:

mir ist aufgefallen, dass die ios.js Datei eine relative Pfadebene zu weit oben nach der jquery.js sucht. 

Diesen Sprung habe ich um eine relative Ebene verkürzt und jetzt funktioniert die Seite problemlos und ohne weitere Proxy Änderung. 

 

Sehr aufmerksam! Das hatte ich noch nicht bemerkt.

 

Die Frage ist, auf welches Verzeichnis sich die relativen Pfade beziehen müssen. Auf den SVCweb\ios-Ordner oder den Ordner des aufrufenden Skripts (SVCweb\ios\js)? Eine kurze Web-Recherche liefert Hinweise, dass Pfadangaben in Skripten  relativ zur aufrufenden Seite sein müssen, z.B. hier. Insofern hättest du mit deiner Korrektur recht. Ich habe sie kurz ausprobiert. Damit funktioniert die Timeline-Seite des Mobil-Webinterface nach wie vor in Desktop-Browsern (wobei sich die Frage stellt, warum es vorher auch funktioniert hat - probieren es  Browser "aus Erfahrung" sowohl seiten- als auch skript-relativ?). Das muss ich mir noch mal gründlicher vornehmen.

 

Das Mobil-Webinterface wurde ursprünglich von dem Erfinder der App nur für iOS gestaltet. Vor einigen Jahren ist der Autor ausgestiegen bzw. hat sich abgesehen von einer kurzen Wiederkehr nicht mehr blicken lassen. Deshalb musste ich die Pflege übernehmen und mich (zumindest anfangs) ohne jegliche Web/Javascript-Kenntnisse einarbeiten. Ein Ergebnis war die Erweiterung auf Android. Dann hat sich glücklicherweise @janee dazugesellt und ebenfalls Beiträge geliefert - er hatte im Gegensatz zu mir sogar ein iPhone! Zusammen sind wir nun schon seit drei Jahren dabei, den Bereich zu ordnen und zu entwanzen (einschließlich Desktop-Webinterface), aber es findet sich immer noch was neues. Willkommen im Club :)

 

Link to post
zerhau
Posted (edited)

Hallo zusammen, 

 

ich habe weiter getestet: 

Die oben angeführten Modifikationen der ios.js bringen die gewünschte Funktionalität mit dem ReverseProxy bei gleichzeitiger Funktion bei direktem Zugriff auf dem Server im lokalen Netzwerk. Die App schaltet unterbrechungsfrei um. 

 

Ich glaube aber dennoch, dass die Mobil-Webseite ein Problem bei der Benutzerverwaltung hat. 

 

Folgende Szenarien lassen mich auf dieses Problem schließen: 

  • Die Timeline funktioniert nicht, wenn in der App Benutzername und Passwort eingetragen ist. 
    • Bei dieser Konstellation tauchen auf dem Reverse-Proxy Zugriffe auf den ursprünglichen Pfad auf, wie er seit der in den oberen Posts durchgeführten Modifikationen eigentlich nicht mehr auftreten dürfte. 
      Hinweis: Der Proxy gibt 404 Fehlermeldungen aus, die auf diesen aufgerufenen Pfad der App schließen lassen: ../../lib/jquery.scrollTo-min.js

Wo die App allerdings diesen Pfad herbekommt ist mir schleierhaft. Anscheinend überschreibt eine Login-Routine Variablen oder Pfade. 

(Sidekick: Im ersten Post haben wir aus der iphone-de.html die Benutzerprüfung für die Elemente Einstellungen und Aufgaben und entfernt. Dadurch und durch dieses Verhalten der App hat sich mein Verdacht auf die nicht ordnungsgemäß funktionierende  Credentialprüfung verhärtet.)

 

EDIT: Ich könnte mir gut vorstellen, dass die Prüfung der Credentials von der Desktop-Variante der Webseite übernommen wird. So würde man sich vermutlich Quellcode sparen können. Hier könnte die Erklärung liegen, weshalb Pfade bei erfolgreichem Login anders gesetzt werden. Das ist aber reine Spekulation und ich möchte anmerken, dass ich diesbezüglich von keiner Sachkenntnis behindert werde!

 

 

  • Die Timeline funktioniert, wenn in der App nur ein Benutzername eingetragen ist. (?!)
    • Bei dieser Konstellation werden die geänderten Pfade in der ios.js richtig interpretiert und die App greift über den angepassten / korrigierten Pfad auf den Reverse-Proxy zu. Voller Funktionsumfang der App ist gewährleistet.
      Es taucht ein Popup fehlender Credentials auf, die App funktioniert aber bislang trotzdem.

 

  • Der Zugriff endet in einem 401 Forbidden, sobald in der App kein Benutzername und kein Passwort eingetragen ist. (Dieses Verhalten ist mindestens gewünscht.)

 

Ich bitte euch deshalb, die Prüfungen bzgl. Benutzername und Passwort zu untersuchen und zu berichtigen, damit auch über die App eine angemessene Autorisierung stattfinden kann. Leider kann ich mit meinem Mitteln nicht überprüfen an welcher Stelle der Fehler passiert. 

Ich hoffe zudem, dass mir bei den zahlreichen Tests nicht irgendwelche Caches einen Strich durch die Rechnung gemacht haben. Das Verhalten war aber mehrfach reproduzierbar.

 

Ich bedanke mich auf jeden Fall schonmal sehr für eure Hilfe und zielführende Zusammenarbeit in dieser Sache. 

Die App bietet wie ich finde den größtmöglichen Komfort eurer Software und ich würde diese einfache Programmierbarkeit des DMS sehr vermissen.  

 

Vielen Dank und schöne Grüße

 

Edited by zerhau
Einfall zur Ursache
Link to post
janee
vor 1 Stunde schrieb zerhau:

Folgende Szenarien lassen mich auf dieses Problem schließen: 

  • Die Timeline funktioniert nicht, wenn in der App Benutzername und Passwort eingetragen ist. 
    • Bei dieser Konstellation tauchen auf dem Reverse-Proxy Zugriffe auf den ursprünglichen Pfad auf, wie er seit der in den oberen Posts durchgeführten Modifikationen eigentlich nicht mehr auftreten dürfte. 

Also ich habe mir gerade einen ReverseProxy mithilfe von caddy eingerichtet und kann kein Problem feststellen, wenn ich in der App Benutzername + Passwort eingebe.

 

Vielleicht löscht du die App einmal vom Gerät und installiest Sie erneut, damit alle im Cache befindlichen Daten gelöscht werden.

 

Die einzige Baustelle, die derzeit noch sehe, sind die Aufgaben und Einstellungen, die nicht erscheinen, trotz der richtigen Zugangsdaten (Admin)

<!-- START BLOCK : withrights2 --> ..... <!-- END BLOCK : withrights2 -->

 

 

Link to post
zerhau
Posted (edited)

Hallo janee,


die Pfadproblematik taucht nur auf, wenn man den Pfad auf eine Subdomain umändert. 

hast du deinen RevProxy so eingerichtet, dass der Proxy eine weitere Ebene hinzufügt? 
Bsp.: 

https://publicdomain/recordingservice/iOS/Index-de.html 

nach

http://internalserver:8089

 

In dieser Konstellation habe ich die aufgezeigten Probleme mit den Pfaden und einem IIS festgestellt. 
 

Die Neuinstallation mache ich gleich mal noch. 
 

EDIT: Die Neuinstallation der App hat’s bis hierhin gebracht! 
Die Timeline funktioniert bei internem wie externem Zugriff. Wahrscheinlich haben die Caches mir einen Streich gespielt! 
Bitte entschuldigt die falsche Fährte! 
Ich sehe momentan auch nur noch das Problem mit dem nicht vollständigen Menü. 
Vielen Dank an @janee und @Griga für euer Engagement!

 

Vielen Dank für deine Mühen!

Edited by zerhau
Link to post
  • 2 weeks later...

Hallo zusammen, 

 

habt ihr schon ein Verfahren oder eine Roadmap wie ihr die Änderungen in künftige Releases einbaut und bis wann ihr den Fix mit den nicht richtig behandelten Credentials-Prüfungen einbaut? 
 

Vielen Dank und schöne Grüße,

 

stzerre

Link to post
Griga

Der von dir hier angegebene Fix wird im nächsten Release enthalten sein. Da du ihn selbst durchführen kannst, brauche ich dafür keinen Hotfix hochladen.

 

Von einer nicht richtig behandelten Credentials-Prüfung weiß ich nichts. Im DMS folgt sie den durch die verwendete Netzwerk-Bibliothek vorgegebenen Pfaden. Probleme sind damit bislang nicht bekannt. Falls es sich auf die App bezieht: Da kannst du nur darauf hoffen, dass sich der Autor hier wieder blicken lässt. Uns stehen weder der Quellcode noch die Entwicklungswerkzeuge noch der Account bei Apple zur Verfügung.

 

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...