- Offizieller Beitrag
@MysteryCode Da geht es nur um die Paket-Listen, das hat mit dem reinen Update- bzw. Installations-Vorgang überhaupt nichts zu tun.
@MysteryCode Da geht es nur um die Paket-Listen, das hat mit dem reinen Update- bzw. Installations-Vorgang überhaupt nichts zu tun.
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.
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.
Das sollte aber nicht Sinn der Sache sein.
Ja schon, aber viecode hat gefragt, wie man die Sache umgehen kann.
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
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
Ich kann dafür kurzfristig leider keine Lösung anbieten.
Eine optimale Funktionsweise scheitert an zwei Faktoren:
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.
dies erfordert die Speicherung von Zugangsdaten für die Paket-Server die vom Sicherheitsaspekt her zu mindestens bedenklich ist.
Das ist doch aktuell (zumindest optional) auch der Fall?
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.
Vielleicht wäre es auch machbar, wobei vielleicht umständlich für den Dau, dass der User ein Ranking der Paket Server per drag and drop vorgeben kann.
Dann wird wenn Updates angegebenen werden on der Reihenfolge der Rankings abgefragt und könnte dann schon helfen...
Sofern das Ranking stimmt...
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.
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.
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!