Wenn ich das richtig verstanden habe ist bei Javascript "DataUrl" eben base64 ja, du erstellst aber ein Canvas, zeichnest dort die Bilddatei als Bitmap nach und speicherst diese.
Und ob du nun einen String verschlüsselt oder eine Datei, kommt auf das selbe heraus.
Wieso kannst du nicht mit Binärdaten arbeiten?
Deine Dateigröße ist ziemlich schnell erklärt da du ein Canvas erstellst, das dürfte als Bitmap passieren. Wieso nutzt du da kein base64?
Bei mir damals dauerte es ca. 1 Tag bis Aktivierung 
Hach, der Radix Kurs sieht so bekannt aus 
vor allem stark nach Shitcoin.
Ich bevorzuge wenn ich nochmal darin investiere weiterhin schnell wachsende Coins die man beim Peak verkauft und in einen Stablecoin schiebt.
Wieso gerade in Bitcoin und nicht in stärker wachsende Coins oder direkt mal in ETFs... zukunftsanlage und so.
Ansonsten, damals nutzte ich Coinbase als es noch aktuell war, könnte es jetzt sogar direkt bei meiner Bank machen, aber investiere da lieber in ETFs nun.
Web & Mobile.
Dann kommt man schon Mal der Auswahl etwas näher.
Da kann man also sagen, HTML/CSS sollten sitzen (sind übrigens keine Programmiersprachen...), denn ohne diese Grundlagen brauchen wir nicht weiter zu machen.
Wenn man ein Backend für Web & mobile zu gleich möchte, ist PHP auch nötig, also sollte man mal mit den Grundlagen darin anfangen, bevor man sich an API Entwicklung und anderen Themen für später widmet. Ein guter Anhaltspunkt ist immer sich eine Sache festzusetzen und das dann auch Mal umzusetzen, zB eine einfache Blog Software, diese dann zB erweitern um über eine API zu steuern und dann kann man entweder 100% nativ mit Kotlin oder 50% nativ mit ReactNative sich an die Entwicklung einer App für mobile herantasten.
Habe auch die App, aber keine Lust immer am Handy zu sein...
Immer? IIRC sind das 5-10 Minuten pro Tag bis man die Ziele pro Tag innerhalb der App erreicht hat....
PS: Das hier ist kein Chat, man muss nicht 100 Einzelbeiträge für eine Antwort erstellen
*packt kristallkugel aus*
*legt kristallkugel auf den tisch*
*sagt eine magische beschwörungsformel auf*
"oh heilige kristallkugel, weshalb kann er seine bildschirmauflösung nicht ändern"
*wartet auf antwort*
Also irgendwie reagiert meine Kristallkugel nicht, vielleicht fehlen ihr einige Infos?
Na dann... lager ich mal teile meines Workloads dahin aus . Gerade getestet, funktioniert einwandfrei.
Das escapen ist gar nicht schwierig? Auf diese Weise öffnest du (Mal wieder) nur Einfallstore für Schwachstellen
Kurze Frage, der Fehler klingt sehr stark nach fehlenden escapen der Eingabe, nimmst du etwa plumb die Eingabe des Nutzers?
Stimmt, MIMO hab ich total vergessen, sehr guter Tipp 
Das kann man mit einem Ticketsystem genau so ja auch umsetzen. Ob das jetzt mit osTicket so geht, weiß ich jedoch nicht.
Intern verwenden wir aktuell ja YouTrack
Ja, dann musst du dir auch den eigentlichen Server anschauen, der hinter dem Proxy steckt.
Hab das jetzt mal kontrolliert und dort von 2MB auf 200MB rauf gegangen, bleibt leider dabei.
Hab client_max_body_size 200M; auch mal Testweise in alle Location Blöcke eingefügt, auch dem wo der Proxy definiert wird, keine Änderung jedoch .
osTicket | Support Ticketing System
so mit das bekannteste, gibt auch noch weitere
Sehe ich jetzt nichts, mir kommt aber eventuell was ein, könnte es daran liegen das NGINX nur ein Proxy ist?
location @octane {
set $suffix "";
if ($uri = /index.php) {
set $suffix ?$query_string;
}
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header Scheme $scheme;
proxy_set_header SERVER_PORT $server_port;
proxy_set_header REMOTE_ADDR $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_pass http://127.0.0.1:9191$suffix;
}Später mal genauer schauen, ich gehe jetzt erstmal schlafen
Am Ende des http-Blocks bevor die Config-Files für die Seiten geladen wird.
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
types_hash_max_size 2048;
server_tokens off;
server_names_hash_bucket_size 128;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}Schon mal über sftp versucht?
Wozu, es geht hier um NGINX, nicht SFTP.
Nutzt du php?
Das Backend ist Laravel ja.
Dann hast du vielleicht die php.ini vergessen.
Es geht weiterhin um NGIXN und nicht PHP, das ebenfalls 2GB annimmt.
Ansonsten in der nginx.conf die direktive client_max_body_size setzen / deklarieren
das mein NGINX Server trotz einer erlaubten Body size von 2GB dieses ablehnt mit der Fehlermeldung Request Entity To Large.
Ich vermeide solch große Uploads immer generell.
Lässt sich bei Bildern nicht immer vermeiden bei gewissen Auflösungen.
Wie wärs wenn du die Datei in chunks hochlädst? Ein Client-side script, dass die datei in 1mb Blöcke unteteilt und diese dann einzelt hochläd. auf dem server kannst du die datei ganz einfach wieder zusammensetzen.
Es auf Frontend-Seite zu zerlegen und als Chunk hochzuladen ist zwar eine "Lösung", löst aber nicht das eigentliche Problem das NGINX trotz einer erlaubten größe bis 2GB schon bei 28mb streikt und das will ich ja gelöst haben.
