Beta-Uploads, technische Frage

[F(R)S-Bauer]

@spaddi

1) Ja hat es gegeben und gibt es, insbesondere die USA benutzen alle Möglichen Quellen um auch Ihre Verbündeten abzuhören und Daten zu klauen, auch aus Wirtschaftlichen Interessen.
2) So was läuft über die FIS Gerichte der USA, deren Sachen sind per Definition lange Geheim, man sieht nur die "Erfolge" und muss Rückfolgern
3) Solche Infos laufen über Justizkanäle bis nach Deutschland rein um Rechtliche Beschränkungen der EU/Deutschland zu umgehen, der Fall Edati ist da ein prominentes Beispiel für, wenn man nicht nur das Ergebnis sieht sondern den Weg mal unter die Lupe nimmt.
4) DSGVO ermöglicht es jeden Käufer und Nutzer gegen den Anbieter zu klagen und recht zu bekommen, egal was ich vorher "Unterschreiben" habe.

5) Ich werde diese Thema nicht hier Weiter diskutieren und Verweise auf z.B. Netzpolitik.org

Hier ist Zusi und das Thema zu Kontrovers und Total OT als Diskussion in ADD-On Pool.

Gruß

Ralf

@ Carsten, bitte ggf. die 2 Beitrage verschieben in eine Passenderen Bereich.

[Carsten Hölscher]

An einer kleinen Stelle komme ich noch nicht ganz zur idealen Lösung. Vielleicht kennt sich ja jemand aus. Idealzustand: Ein Bastler lädt sein Werk hoch in ein Verzeichnis, auf das niemand lesend zugreifen kann. Dann erfolgt durch einen Admin ein kurzer Check, ob es sich nich tum groben Unfug handelt und das Werk wird als beta verfügbar gemacht.
Sowas get mit Nextcloud über eine filedrop-Function per Browser. Man bekommt also einen etwas kryptischen Link, der öffnet im Browser eine Seite, auf die man seine Datei per Drag+Drop ziehen kann und dann verschwindet sie unzugänglich in der Cloud bis der Admin sie freigibt.
Diese function würde ich gerne zur einfacheren Handhabung in die Verwaltung integrieren, mir fehlt aber der Ansatz dafür.
Die sonstigen Funktionen wie Auslesen der Cloudstruktur, Daten runterladen usw. (dann mit explizitem user-login) per webDAV gehen im Testbetrieb.

Carsten

[Johannes]

Clientseitig einen eindeutigen Dateinamen generieren (GUID) und dann ganz normal (per WebDAV bzw. HTTP PUT) in den freigegebenen File-Drop-Ordner hochladen funktioniert nicht? https://docs.nextcloud.com/server/16/de ... ding-files

Es gibt da wohl noch ein paar Tricks, die man anwenden muss (Ordnername als Benutzername, leeres Passwort, Header "X-Requested-With: XMLHttpRequest").

[Carsten Hölscher]

An den Tricks scheitert es vermutlich...

Carsten

[Johannes]

Laut https://docs.nextcloud.com/server/16/us ... ebdav.html:

"use the share token as username and the (optional) share password as password."

Wenn ich das recht verstanden habe, ist das Token der 15-stellige String am Ende der "kryptischen" URL.

Das wäre mal als erstes zu versuchen. Was kommt dann als Antwort?

[Carsten Hölscher]

mit 'X-Requested-With: XMLHttpRequest' kommt "Cannot authenticate over ajax calls".

(und ohne "No public access to this resource., Username or password was incorrect, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, Username or password was incorrect")

Clientseitig einen eindeutigen Dateinamen generieren (GUID)

Zum Testen sollte es ja reichen einen Namen zu nehmen, den es auf dem Server noch nicht gibt, oder?

Carsten

[johannes4321]

mit eine Normale FTP Zugang bist du nicht mehr mehr Datenschutzgrundverordnung-Konform. Auch ist es Theoretisch (und mit Routerzugriff auch praktisch) möglich Daten mit zu lesen und zu manipulieren.

Ich würde davon ausgehen, dass jeder FTP Server in 2021 FTP-via-TLS (aka. TLS-vis-SSL aka ftps) macht und dadurch Übertragunssicherheit gewährleistet ist.(sftp aka. ftp via ssh) hat verschiedene andere operative Vorteile.

DSGVO ist dabei aber nur sehr bedingt ein Thema. DSGVO behandelt personenbezogene Daten. Um die geht es nur bedingt. Das einzige personenbezogene Datum hier ist der Name und die Namen der Beitragenden werden in diesem Prozess so oder so veröffentlicht. Fragen hier sind Integrität der Daten und Workflows.

Auf technischer Ebene würde ich aber entweder etwas HTTP-basiertes (der genauer: https, also HTTP via TLS) machen. Das erzeugt die wenigsten Probleme in Zugriffsteuerung, Firewalls, ... und ermöglicht die Anbindung einer beliebigen Validierung auf Serverseite. Oder eben basierende auf Software-Versionskontrollsystemen wie git. Das hat seine Tiefen, die wesentliche Problematik ist aber so oder so die Konflikbehandlung konkurrierender Änderungen, die man entweder durch strikte Hierarchie (nur Arno Nym darf gewisse Dinge Ändern und weiterreichen und dabei Konflikte auflösen) oder eben durch "die Basis" geschehen. Ein Tool wie git kann da helfen, da es eine gewisse Struktur erzwingt, erfordert aber das Lernen der Prozesse. (und bietet eine Gefahr und Untiefen, da es alle möglichen Manipulationen am zugrundeliegenden Versons-Graphen erlaubt ...)

Für mich als Außenstehenden macht ein Projekt-Managment/Ticket tool (sei es Jira oder GitHub/GitLab oder irgendwas "einfaches") unabhängig davon Sinn, da es erlaubt den Status zu verfolgen ohne sich durch ausufernde Forendisukussionen (wie diesen Beitrag hier, der wenig bis nichts zur Sache beiträgt) quälen zu müssen.

[F(R)S-Bauer]

...
DSGVO ist dabei aber nur sehr bedingt ein Thema. DSGVO behandelt personenbezogene Daten. Um die geht es nur bedingt. Das einzige personenbezogene Datum hier ist der Name und die Namen der Beitragenden werden in diesem Prozess so oder so veröffentlicht. Fragen hier sind Integrität der Daten und Workflows.
...

Die Kleine Chemiebude aus Ludwigshafen mit 4 Buchstaben, die uns gekauft hat sieht das Deutlich anders.
Wir müßten sehr viele bewährte Übertagungen wegen DSGVO einstellen, sobald auch nur ein Zuordbarer Name drin ist. Auch wenn der nichts mit dem Benutzer zu tun hat sondern ganz anders lautet.

Gruß

Ralf