Priorität der Updateserver - Plugin nicht im Store, sondern beim Hersteller erworben

  • Aktuell ist der Unmut leider groß, denn viele haben beim Hersteller Produkte gekauft und dieser besitzt auch einen Updateserver. Wenn jetzt entsprechend das Produkt sowohl auf dem Updateserver des Herstellers, als auch des Plugin-Stores vorhanden ist, nimmt das System IMMER den Updateserver des Stores. Hier sehe ich persönlich einen sehr großen Nachteil, denn man müsste somit fürs Updaten den Store Updateserver deaktivieren, damit der Update klappt. Daher mein Vorschlag das entsprechend die Priorität im System des Store Updateservers unter den der anderen Updateserver steht, damit erst alle anderen Updateserver benutzt werden und ganz am Schluss erst der vom Store, denn es ist sehr unerfreulich wenn man ein Paket beim Hersteller erworben und nicht updaten kann, da man das Paket nicht im Store erworben hat und somit nicht updaten kann.


    Die Kundenverwaltung lässt leider mangels niedriger Priorität noch auf sich warten, weshalb ich hoffe das wenigstens dieser Vorschlag schneller umgesetzt wird, denn alles andere wäre nur für die Kunden ärgerlich, wenn diese das automatische Updatesystem nicht nutzen können, weil die Prioritäten des System falsch liegen.

  • Ich weiß nicht, aber wäre das nicht ne Art Sicherheitslücke?!


    Ich erkläre kurz ohne jemandem etwas unterstellen zu wollen:
    Werden erst alle anderen Server vor dem Store abgefragt besteht die Gefahr, dass andere Server scheinbar offizielle WCF-/WBB-Pakete updaten und somit Schadcode direkt in die WCF-/WBB-Software einbinden könnten - ergo Klassen der beiden Pakete ersetzen können.

  • Den Schadcode kannst du dir mit fremden paketserver so oder so einfangen.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

  • Werden erst alle anderen Server vor dem Store abgefragt besteht die Gefahr, dass andere Server scheinbar offizielle WCF-/WBB-Pakete updaten und somit Schadcode direkt in die WCF-/WBB-Software einbinden könnten - ergo Klassen der beiden Pakete ersetzen können.


    Der Paketserver des PlugIn Stores ist nicht der Selbe, wie der Updateserver von WoltLab für das WCF/WBB.
    Man könnte also immernoch zuerst den Update-Server von WoltLab abfragen und als letztes erst den Store.

  • Der Paketserver des PlugIn Stores ist nicht der Selbe, wie der Updateserver von WoltLab für das WCF/WBB.
    Man könnte also immernoch zuerst den Update-Server von WoltLab abfragen und als letztes erst den Store.


    Stimmt natürlich auch wieder... dann müssten halt die WoltLab Server für WCF/WBB zuerst kommen, dann andere Server und zum Schluss die Store-Server.

  • Am meisten Sinn würde es wohl machen, wenn der Forenbetreiber selber die Prioritäten in der Updateserverübersicht festlegen könnte.

    MfG Markus Zhang (aka RouL)

  • Gibt es diesbezüglich schon etwas neues? Bei jedem Update haben meine Kunden das Problem, dass sie nicht updaten können und verstehen das Problem auch nicht (v.a. den Unterschied zwischen meinem Paketserver und den vom Plugin-Store und warum sie darauf keinen Zugriff haben). Das ist extrem nervig, weil es vor allem auch meine Kunden verärgert.

  • Kann mir jemand das hier sinnvoll in Hinsicht auf dieses Thema erklären?
    github.com/WoltLab/WCF/blob/ma…eDispatcher.class.php#L45

    https://github.com/WoltLab/WCF…23ae40c3132edeb2070ace316


    => Man versucht es zu erst bei den WL Servern, da man von diesen annimmt, dass diese am ehesten verfügbar sind. Gibt es da einen Timeout, so wird SSL abgeschaltet und ohne weitergemacht.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!