JVerein - Wie kann es weitergehen?

JVerein-Benutzer diskutieren über Erweiterungswünsche

Moderator: heiner

NicoB77
Beiträge: 117
Registriert: Freitag 21. April 2017, 21:14
Verein: Pollingua e.V.
Mitglieder: 50
JVerein-Version: Entwicklerversion
Betriebssystem: Linux

Re: JVerein - Wie kann es weitergehen?

Beitrag von NicoB77 »

Damit man in Jameica auf den Fork umsteigen kann, ohne jedes Release von Hand herunterladen und installieren zu müssen, habe ich ein Jameica-Repository für openjverein (in der existierenden Github Page) eingerichtet und den Build so angepasst, dass die openjverein-URLs verwendet werden. Leider muss in das Repository das Plugin-Archiv aus dem Github-Release nochmal hochgeladen werden, weil Jameica den Download direkt aus dem Github-Release nicht unterstützt. Es gibt Pull-Requests für beides.

Viele Grüße
Reinhard
NochEinRainer
Beiträge: 2
Registriert: Mittwoch 13. April 2022, 10:32
Verein: Verein für Kulturelle Bildung Eichenau

Re: JVerein - Wie kann es weitergehen?

Beitrag von NochEinRainer »

phschoen hat geschrieben: Dienstag 31. Mai 2022, 11:20 echt doof das man hier keine emails bekommt wenn was neues geschrieben wurde
Du bekommst Nachrichten wenn du das Thema abonnierst. Und du kannst auch im persönlichen Bereich einstellen, das Themen die du startest oder in denen du schreibst, automatisch abboniert werden.
Thema_abonieren-1.jpg
Thema_abonieren-1.jpg (3.67 KiB) 243 mal betrachtet
Thema_abonieren-2.jpg
Thema_abonieren-2.jpg (9.62 KiB) 243 mal betrachtet
Thema_abonieren-3.jpg
Thema_abonieren-3.jpg (10.23 KiB) 243 mal betrachtet
NochEinRainer
Beiträge: 2
Registriert: Mittwoch 13. April 2022, 10:32
Verein: Verein für Kulturelle Bildung Eichenau

Re: JVerein - Wie kann es weitergehen?

Beitrag von NochEinRainer »

Sodala,

es freut mich sehr das es mit JVerein weiter geht, denn ich bin seit ein paar Wochen Kassierer im Verein für kulturelle Bildung Eichenau und prinzipiell Nutzer von freier Software. Ich denke JVerein wird mir die Arbeit erleichtern. Da programmieren für mich eher ein Fremdwort ist kann ich zumindest hierbei nicht helfen. Aber bedanke mich erst einmal herzlich für eure Arbeit.

Grüße
Rainer
Benutzeravatar
hibiscus
Beiträge: 25
Registriert: Donnerstag 31. Mai 2018, 08:55

Re: JVerein - Wie kann es weitergehen?

Beitrag von hibiscus »

NicoB77 hat geschrieben: Samstag 4. Juni 2022, 19:22 Damit man in Jameica auf den Fork umsteigen kann, ohne jedes Release von Hand herunterladen und installieren zu müssen, habe ich ein Jameica-Repository für openjverein (in der existierenden Github Page) eingerichtet und den Build so angepasst, dass die openjverein-URLs verwendet werden. Leider muss in das Repository das Plugin-Archiv aus dem Github-Release nochmal hochgeladen werden, weil Jameica den Download direkt aus dem Github-Release nicht unterstützt. Es gibt Pull-Requests für beides.
Ich schaue nicht regelmäßig in das Forum hier, daher bin ich eher zufällig über eure Initiative gestolpert. Der Fork ist doch schonmal ein guter Anfang.
Hast du irgendwelche Detail-Infos, warum der Direkt-Download der Github-Releases vom Jameica-Pluginmanager nicht funktioniert? Hast du hier vielleicht einen Stacktrace?
Benutzeravatar
hibiscus
Beiträge: 25
Registriert: Donnerstag 31. Mai 2018, 08:55

Re: JVerein - Wie kann es weitergehen?

Beitrag von hibiscus »

sbuer hat geschrieben: Dienstag 19. April 2022, 16:31 Hier im Forum wurde ja bereits bemängelt, das beispielsweise ein Abrechnungslauf ohne hibiscus zwar in eine SEPA XML geschrieben wird - aber halt in einer alten Version. Hier habe ich selbst mal den Programmcode geprüft und festgestellt, daß die SEPA XML mit Hilfe von obantoo-bin-2.1.12 erzeugt wird. (jverein nutzt quasi die dort enthaltenen Klassen und das Tool kennt leider nur die alte Sepa Version). Das entsprechende jar File wurde allerdings von Heiner erzeugt und steht demnach unter seiner Obhut.
Hibiscus kann ja ebenfalls SEPA XML erstellen. Auch alle aktuellen Versionen. Hierbei wird intern HBCI4Java verwendet. Da JVerein ohnehin ein installiertes Hibiscus verlangt (egal, ob man es nutzt oder nicht), könnte man den in jVerein integrierten SEPA-XML-Export auch auf HCBI4Java umstellen und hätte Support für alle SEPA-Versionen. Der Code dafür ist nicht sonderlich komplex und könnte sicher einfach in JVerein eingebaut werden. In Hibiscus passiert das in: https://github.com/willuhn/hibiscus/blo ... r.java#L84
NicoB77
Beiträge: 117
Registriert: Freitag 21. April 2017, 21:14
Verein: Pollingua e.V.
Mitglieder: 50
JVerein-Version: Entwicklerversion
Betriebssystem: Linux

Re: JVerein - Wie kann es weitergehen?

Beitrag von NicoB77 »

hibiscus hat geschrieben: Montag 13. Juni 2022, 10:34 Ich schaue nicht regelmäßig in das Forum hier, daher bin ich eher zufällig über eure Initiative gestolpert. Der Fork ist doch schonmal ein guter Anfang.
Hast du irgendwelche Detail-Infos, warum der Direkt-Download der Github-Releases vom Jameica-Pluginmanager nicht funktioniert? Hast du hier vielleicht einen Stacktrace?
Der Download scheitert erst an einem Redirect, der nicht akzeptiert wird. Als ich das zugelassen habe, gab es folgende Fehlermeldung:

Code: Alles auswählen

[Mon Jun 13 17:38:05 CEST 2022][INFO][main][de.willuhn.jameica.gui.internal.parts.PluginListPart.loadAvailable] start search for available plugins
[Mon Jun 13 17:38:05 CEST 2022][INFO][repo-fetch available][de.willuhn.jameica.update.Repository.<init>] open repository https://nicob77.github.io/jameica-repository
[Mon Jun 13 17:38:05 CEST 2022][INFO][repo-fetch available][de.willuhn.jameica.transport.HttpTransport.get] downloading https://nicob77.github.io/jameica-repository/repository.xml
[Mon Jun 13 17:38:05 CEST 2022][WARN][repo-fetch available][de.willuhn.jameica.update.PluginGroup.initCertificate] no certificate given
[Mon Jun 13 17:38:05 CEST 2022][INFO][repo-fetch available][de.willuhn.jameica.transport.HttpTransport.get] downloading https://nicob77.github.io/jameica-repository/plugin.xml
[Mon Jun 13 17:38:05 CEST 2022][INFO][repo-fetch available][de.willuhn.jameica.gui.internal.parts.PluginListPart$3.run] search done, found 1 plugins/version
[Mon Jun 13 17:38:12 CEST 2022][INFO][bg-task:][de.willuhn.jameica.update.Repository$1.run] checking if plugin jverein is signed
[Mon Jun 13 17:38:16 CEST 2022][INFO][bg-task:][de.willuhn.jameica.update.Repository$1.run] creating deploy file /home/reinhard/repo_test/updates/jverein.zip
[Mon Jun 13 17:38:16 CEST 2022][INFO][bg-task:][de.willuhn.jameica.transport.HttpTransport.get] downloading https://github.com/openjverein/jverein/releases/download/2.8.19/jverein.2.8.19.zip
[Mon Jun 13 17:38:17 CEST 2022][INFO][bg-task:][de.willuhn.jameica.transport.HttpTransport.getConnection] got redirect from https://github.com/openjverein/jverein/releases/download/2.8.19/jverein.2.8.19.zip to https://objects.githubusercontent.com/github-production-release-asset-2e65be/472761177/948715e5-66e5-4ab1-87c2-4cfb77abd008?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A/20220613/us-east-1/s3/aws4_request&X-Amz-Date=20220613T153817Z&X-Amz-Expires=300&X-Amz-Signature=ce72fe40daa2675090225b6bd72189890e6fd18df7055d5a827d96e404f98647&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=472761177&response-content-disposition=attachment; filename=jverein.2.8.19.zip&response-content-type=application/octet-stream
[Mon Jun 13 17:38:17 CEST 2022][INFO][bg-task:][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor.check] creating progress monitor for GUI
[Mon Jun 13 17:38:17 CEST 2022][INFO][main][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor$2.run] activating progress monitor
[Mon Jun 13 17:38:17 CEST 2022][ERROR][bg-task:][de.willuhn.jameica.update.Repository$1.run] error while downloading file
java.io.IOException: Server returned HTTP response code: 400 for URL: https://objects.githubusercontent.com/github-production-release-asset-2e65be/472761177/948715e5-66e5-4ab1-87c2-4cfb77abd008?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A/20220613/us-east-1/s3/aws4_request&X-Amz-Date=20220613T153817Z&X-Amz-Expires=300&X-Amz-Signature=ce72fe40daa2675090225b6bd72189890e6fd18df7055d5a827d96e404f98647&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=472761177&response-content-disposition=attachment; filename=jverein.2.8.19.zip&response-content-type=application/octet-stream
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1974)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1969)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1968)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1536)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1512)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1510)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:795)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
	at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:250)
	at de.willuhn.jameica.transport.HttpTransport.get(HttpTransport.java:140)
	at de.willuhn.jameica.update.Repository$1.run(Repository.java:218)
	at de.willuhn.jameica.gui.GUI$7.run(GUI.java:1081)
Caused by: java.io.IOException: Server returned HTTP response code: 400 for URL: https://objects.githubusercontent.com/github-production-release-asset-2e65be/472761177/948715e5-66e5-4ab1-87c2-4cfb77abd008?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A/20220613/us-east-1/s3/aws4_request&X-Amz-Date=20220613T153817Z&X-Amz-Expires=300&X-Amz-Signature=ce72fe40daa2675090225b6bd72189890e6fd18df7055d5a827d96e404f98647&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=472761177&response-content-disposition=attachment; filename=jverein.2.8.19.zip&response-content-type=application/octet-stream
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1924)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1512)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1510)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:795)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
	at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
	at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:334)
	at de.willuhn.jameica.transport.HttpTransport.getConnection(HttpTransport.java:219)
	at de.willuhn.jameica.transport.HttpTransport.get(HttpTransport.java:123)
	... 2 more
Benutzeravatar
hibiscus
Beiträge: 25
Registriert: Donnerstag 31. Mai 2018, 08:55

Re: JVerein - Wie kann es weitergehen?

Beitrag von hibiscus »

Das ist merkwürdig. Jameica unterstützt schon seit 2018 Redirects (https://github.com/willuhn/jameica/comm ... 0bc23860f2)

Hierfür wird der HTTP Statuscode ausgewertet. 301 und 302 sind die bekannten Codes dafür. Auf die URL https://github.com/openjverein/jverein/ ... 2.8.19.zip antwortet der Server auch mit einem Redirect, der korrekt interpretiert und dem gefolgt wird. Danach kommt aber ein HTTP-Code 400 zurück. Der steht für "BAD REQUEST". Wenn ich https://github.com/openjverein/jverein/ ... 2.8.19.zip im Browser oder per wget abrufe, funktioniert das.

Ich kann mir gerade nicht erklären, warum das nicht geht.

Die vom Github-Server als Weiterleitung zurückgemeldete URL enthält ein Leerzeichen in "attachment; filename":
https://objects.githubusercontent.com/g ... attachment; filename=jverein.2.8.19.zip&response-content-type=application/octet-stream

Unter Umständen ist das die Ursache.

PS: Eigentlich erlaubt Jameica Redirects ja nur, wenn sich der Hostname dabei nicht ändert. Das Verhalten ist auch nicht konfigurierbar. Kann es sein, dass du die Prüfung zum Test aus Jameica ausgebaut hattest? In dem Fall könntest du in HttpTransport in Zeile 240 mal das "loc = URLDecoder.decode(loc, "UTF-8");" auskommentieren. Das macht aus dem "%20" in der Redirect-URL wieder ein " ". Vielleicht ist das ja die Ursache.
NicoB77
Beiträge: 117
Registriert: Freitag 21. April 2017, 21:14
Verein: Pollingua e.V.
Mitglieder: 50
JVerein-Version: Entwicklerversion
Betriebssystem: Linux

Re: JVerein - Wie kann es weitergehen?

Beitrag von NicoB77 »

Genau, zum Testen hatte ich Zeile 247 verändert:

Code: Alles auswählen

if (!StringUtils.equalsIgnoreCase(s1,s2) && !(StringUtils.equalsIgnoreCase(s1, "github.com") && StringUtils.equalsIgnoreCase(s2, "objects.githubusercontent.com")))
Wenn ich zusätzlich Zeile 240 auskommentiere, funktioniert der Download.
Benutzeravatar
hibiscus
Beiträge: 25
Registriert: Donnerstag 31. Mai 2018, 08:55

Re: JVerein - Wie kann es weitergehen?

Beitrag von hibiscus »

Mhh, hatte ich mir schon fast gedacht. Schwierige Entscheidung. Eigentlich halte ich den Redirect-Schutz für ein sinnvolles Feature. Man könnte das zwar konfigurierbar machen. Allerdings wäre das eine dieser typischen Optionen, bei denen die meisten User gar nicht verstehen, was die Option eigentlich macht. Hinzu kommt: Sinnvollerweise müsste die Redirect-Erlaubnis per Default inaktiv sein (also dem Paradigma "Security by Default" folgen). Dann müssten aber alle User diese Option erst deaktivieren, bevor sie das Open-JVerein-Repo nützen können. Auch keine schöne Lösung. Die pragmatischere Lösung ist dann vielleicht doch, dass du die Downloads nach der Erstellung nochmal per Hand an einen Ort kopierst, von dem aus sie ohne Redirect erreichbar sind. Dann hättest du auch nochmal einen manuellen Arbeitsschritt zur Freigabe eines Release. Das senkt auch das Risiko, dass mal versehentlich ein kaputtes Release sofort bei den Usern landet, weil du die Chance hast, es vorher nochmal zu testen.
Antworten