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

  • Ich sag meinen Kunden immer, sie sollen den Woltlab Server kurz deaktivieren, wenn sie meinen nutzen wollen. Hat bisher immer funktioniert.

  • gn5VmUKCtv6ekrMf Da geht es nur um die Paket-Listen, das hat mit dem reinen Update- bzw. Installations-Vorgang überhaupt nichts zu tun.

    Vorschnell sinnlose Schlüsse aus einem Kommentar gezogen ohne die Datei weiter anzusehen. :whistling:


    Kannst du bitte mal die technischen Gründe und notwendigen Informationen nennen, die euer Server scheinbar noch nicht ausliefert? :)
    Ja, ich könnte auch den Code durchforsten...





    Ich sag meinen Kunden immer, sie sollen den Woltlab Server kurz deaktivieren, wenn sie meinen nutzen wollen. Hat bisher immer funktioniert.

    Das sollte aber nicht Sinn der Sache sein.

  • Die Lösung hab ich bereits auch gefunden und es gibt von mittlerweile auch eine Anleitung für meine Kunden. Das Problem ist, dass die meisten die Anleitung sowieso nicht lesen. Das führt zu zwei Punkten

    • Der Kunde ist frustriert / verärgert. Bei jedem Update bekomm ich die selben Fragen und der Kunde ist in der Regel verärgert, weil er glaubt ich hab seine Lizenz gelöscht o.ä.. Das Problem ist immer, dass der Kunde nicht versteht, dass er über die Plugin-Store Server nicht updaten kann, wenn er bei mir gekauft hat. Die Einrichtung meines Paketservers behebt aber nicht das Problem. Bei jedem neuen Update wiederholt sich das selbe Problem!
    • Ich muss bei jedem Update die selben Fragen zum Updaten beantworten. Schön langsam nervt es mich auch, aber ich kann nichts dagegen tun. Wir haben das Problem seit Ewigkeiten und jetzt gibt es dafür eine Lösung, aber sie wird vom offiziellen Paketserver nicht unterstützt?! Warum macht man dann eine Lösung, wenn es keine Verbesserung bringt?

    Was muss der Updateserver konkret ausliefern, damit der Fehler nicht aufritt?

  • Dieser Umweg ist bekannt, die Kunden verstehen nur meist nicht warum dieser Schritt notwendig ist, da das WCF diese Funktion ja unterstützt (siehe Label) und dieser Mehraufwand ja auch wirklich unnötig ist ;)

    • Official Post

    Ich kann dafür kurzfristig leider keine Lösung anbieten.



    Eine optimale Funktionsweise scheitert an zwei Faktoren:

    • Das accessible-Attribut bietet im Grundansatz eine Teillösung an, hat allerdings zum Nachteil das die Paket-Listen dynamisch ausgeliefert werden müssen. Dies erfordert eine explizite Authentifizierung, da andernfalls die exakte Verfügbarkeit nicht ermittelt werden kann, dies erfordert die Speicherung von Zugangsdaten für die Paket-Server die vom Sicherheitsaspekt her zu mindestens bedenklich ist. Die dynamische Auslieferung ist für uns aus technischen Gründen nicht wirklich eine Option, wir verteilen ab WCF 2.1 die Paket-Liste sogar direkt über das CDN (= statisch)
    • Beim Versuch des Downloads über die Paket-Server wird stur der erste Server verwendet, der eine Verfügbarkeit signalisiert (= accessible="true"), es ist in der Implementierung nicht vorgesehen einen spezifischen Paketserver zu nutzen, außer man deaktiviert alle anderen. Im Abfragedialog selbst ist es auch nicht möglich die Authentifizierung zu ignorieren und zum nächsten Server über zu gehen

    Die Funktionsweise der Paket-Server entspricht im Großen und Ganzen immer noch der Implementierung von WCF 1.0, es hat sich zwar technisch einiges unter der Haube getan, aber die grundsätzlichen Ablaufmuster sind immer noch identisch. Ich habe eine Reihe von verschiedenen Ideen wie man dies besser Lösen kann, allerdings ist der Aufwand verhältnismäßig hoch und auf elementaren Bedeutung der Paket-Server gehe ich tendenziell eher konservativ mit diesem Thema um.


    Ich habe diesen Punkt weiterhin auf meiner Todo-Liste und strebe an dies mit WCF 2.2 entsprechend so umzugestalten, dass diese ganzen Probleme der Vergangenheit angehören. Bis dahin wird es aber aus den oben genannten Gründen von unserer Seite aus keine angemessene Lösung geben.

  • ich mah das ganze nochmal auf nachdem ich darauf hingewiesen wurde.

    dies erfordert die Speicherung von Zugangsdaten für die Paket-Server die vom Sicherheitsaspekt her zu mindestens bedenklich ist

    wenn man andere Daten nimmt oder ein oauth/cookie system nutzt (man kann ja sagen du kannst nur paketserver nutzung oder whatever wenn diese daten bzw dieser cookie genutzt werden) ist das Problem weniger drastisch.


    oder aber auch


    was ja sehr interessant wäre dass man im prinzip das API-Keys system ausnutzt und it einem extra parameter sagt, gratis oder nicht gratis und bei nicht gratis plugins wird via API key gefragt, "hab ich oder nicht?" und beim DL kann man dann die Userdaten eingeben und Zünden.

    aus angst vor Capslock nutze ich selten shift.


    in fear of capslock I rarely use shift.

  • was auch helfen könnte wäre wenn der nicht nach dem motto match first, drop rest gehen würde sondern alle prüft und zumindest bei gespeicherten logindaten (NICHT empfohlen) der schau wo es wirklich geht.

    aus angst vor Capslock nutze ich selten shift.


    in fear of capslock I rarely use shift.

  • Ja das wäre auch ne möglichkeit.


    Sprich beim Update werden alle verfügbaren Updates abgefragt, und dann nacheinander abgeklappert. Die Zugangsdaten sind im acp ja eh hinterlegt. Wenn der dann merkt ist zwar auf dem woltlab paketsercer drauf aber kann nicht abgerufen werden weil Zugangsdaten nicht stimmen dann soll er den überspringen keine Fehlermeldung ausgeben und direkt den nächsten verfügbaren paketsercer nutzen

  • Der einfachste Weg ist doch, man bietet das Plugin im Store einfach erst eine Woche später an und fertig. Bei den meisten Anbietern kann man sich ja auch nach Legitimation freischalten lassen, wenn man die paar Tage nicht warten will.

  • Oft ist es ja bereits so dass die plugins auf Hersteller paketserver zu erst erscheinen weil im störe erst noch eine Überprüfung statt findet bis es freigeschaltet wird. Und extra eine Verzögerung einzubauen um dem Problem aus dem weg zu gehen halte ich nicht für richtig.
    Da wird es auf Programmierer Seite sicherlich angenehmere Lösungen geben

  • meine Idee wäre eben beim firstinstall entweder zu fragen oder eben nach prio arbeiten und sich den server merken und immer den für updates nutzen.

    aus angst vor Capslock nutze ich selten shift.


    in fear of capslock I rarely use shift.

  • Ich habe es für mich so gelöst, dass ich die WL-Server kurzer Hand aus der Liste geschmissen habe und zur Sicherheit die Datenbank bereinigt habe (ob das nun gemacht werden muss oder nicht, sei mal dahingestellt).
    Danach habe ich die WL-Server einfach wieder ins System eingebunden und fertig, frei nach dem Motto: Erst die Anbieter direkt, dann Woltlab.


    Dies wäre momentan eine Möglichkeit, aber ob das auch jeder Besitzer so umsetzen kann, zumind. das Löschen und erneute Hinzufügen von Updateservern und das manuelle Ausführen des dazu passenden Cronjobs, sei hier einmal hingestellt.

    Gruß


    Marcel
    -------------------------------------------
    Meine HP: DeltaNet Production


    Derzeit in Programmierung:

    • nichts

Participate now!

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