nicht angemeldet
TS
TS
Felix Riesterer
Rolf B
Rolf B
TS
TS
Felix Riesterer
Felix Riesterer
JürgenB
Felix Riesterer
Hallo
Artikel gefällt, ich teste das jetzt mal.
Ansicht auf dem Handy vom Artikel ist gut Ansicht von der Option (ansehen...) ist ehr schlecht gelöst.
Gruß Marko
Hello,
Artikel gefällt, ich teste das jetzt mal.
Ansicht auf dem Handy vom Artikel ist gut Ansicht von der Option (ansehen...) ist ehr schlecht gelöst.
Bevor Du dein Ergebnis dann in die Öffentlichkeit entlässt, schau dir bitte auch die weiterführenden Hinweise zum Thema an.
Schlecht abgesicherte Dateiuploads sind eines der Haupteinfallstore für Schadsoftware.
Glück Auf
Tom vom Berg
Schlecht abgesicherte Dateiuploads sind eines der Haupteinfallstore für Schadsoftware.
So isses. Es ist jedoch ganz einfach Uploads sicher zu machen: Der Anwender darf weder Dateiname noch Verzeichnis festlegen. MFG
Schlecht abgesicherte Dateiuploads sind eines der Haupteinfallstore für Schadsoftware.
So isses. Es ist jedoch ganz einfach Uploads sicher zu machen: Der Anwender darf weder Dateiname noch Verzeichnis festlegen.
ohne den Troll(?) füttern zu wollen, nur für Anfänger: Obiges ist nur ausreichend, wenn man verstanden hat, warum das ausreichend sein kann, sonst kann man auch das noch relativ einfach falsch machen.
Schlecht abgesicherte Dateiuploads sind eines der Haupteinfallstore für Schadsoftware.
So isses. Es ist jedoch ganz einfach Uploads sicher zu machen: Der Anwender darf weder Dateiname noch Verzeichnis festlegen.
ohne den Troll(?) füttern zu wollen, nur für Anfänger: Obiges ist nur ausreichend, wenn man verstanden hat, warum das ausreichend sein kann, sonst kann man auch das noch relativ einfach falsch machen.
Ohne Dir zu nahe treten zu wollen: Diese einfachen Dinge schafft jeder Anfänger! Umso erstaunlicher daß sie im Wikiartikel nicht einmal erwähnt werden.
Hello Rolf,
Schlecht abgesicherte Dateiuploads sind eines der Haupteinfallstore für Schadsoftware.
So isses. Es ist jedoch ganz einfach Uploads sicher zu machen: Der Anwender darf weder Dateiname noch Verzeichnis festlegen.
ohne den Troll(?) füttern zu wollen, nur für Anfänger: Obiges ist nur ausreichend, wenn man verstanden hat, warum das ausreichend sein kann, sonst kann man auch das noch relativ einfach falsch machen.
Ohne Dir zu nahe treten zu wollen: Diese einfachen Dinge schafft jeder Anfänger! Umso erstaunlicher daß sie im Wikiartikel nicht einmal erwähnt werden.
Da hast Du dir jetzt die 《I》nitiativstrafe verdient. Ergänze den Artikel bitte kurz und knackig :-P
Glück Auf
Tom vom Berg
Hello,
Schlecht abgesicherte Dateiuploads sind eines der Haupteinfallstore für Schadsoftware.
So isses. Es ist jedoch ganz einfach Uploads sicher zu machen: Der Anwender darf weder Dateiname noch Verzeichnis festlegen.
ohne den Troll(?) füttern zu wollen, nur für Anfänger: Obiges ist nur ausreichend, wenn man verstanden hat, warum das ausreichend sein kann, sonst kann man auch das noch relativ einfach falsch machen.
Und es gibt immer noch genügend Möglichkeiten, auch wenn Pfad und Dateiname vom System festgelegt werden.
Glück Auf
Tom vom Berg
Und es gibt immer noch genügend Möglichkeiten, auch wenn Pfad und Dateiname vom System festgelegt werden.
Das soll ja auch nicht vom System festgelegt werden sondern vom Betreiber der Anwendung serverseitig. Und der Programmierer sollte dazu die Voraussetzungen schaffen können, z.B. derart das der Name fürs Uploadverzeichnis konfigurierbar ist und die Dateien einfach nur fortlaufende Nummern bekommen.
MFG
Lieber pl,
Das soll ja auch nicht vom System festgelegt werden sondern vom Betreiber der Anwendung serverseitig.
ich glaube @TS meinte genau das mit "System".
Und der Programmierer sollte dazu die Voraussetzungen schaffen können, z.B. derart das der Name fürs Uploadverzeichnis konfigurierbar ist und die Dateien einfach nur fortlaufende Nummern bekommen.
Wenn die Dateien fortlaufend nummeriert werden, warum die Verzeichnisse dann nicht auch? Meiner Meinung nach braucht es Zufallsnamen, die von der Anwendung "übersetzt" werden, damit es sich für den jeweiligen User so anfühlt, als würden die Dateien (und von mir aus auch Verzeichnisse) genau so lauten, wie er sie benannt hat, in Wirklichkeit aber ist eine Anonymisierungsschicht dazwischen, um direkte Aufrufe über einen URL zu verhindern. Auch braucht es dann vielleicht keine Verzeichnisse mehr, da alle Dateien mit ihren Zufallsnamen (selbstredend sorgt die Anwendung dafür, dass keine Kollisionen entstehen) in eben ein und dem selben Verzeichnis liegen können.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
Wenn die Dateien fortlaufend nummeriert werden, warum die Verzeichnisse dann nicht auch?
Bei einer fortlaufenden Nummerierung ist zu erwähnen, dass man hier die Dateinamen dann leicht erraten kann. Das muss kein Problem sein, kann aber eins sein.
Auch braucht es dann vielleicht keine Verzeichnisse mehr, da alle Dateien mit ihren Zufallsnamen (selbstredend sorgt die Anwendung dafür, dass keine Kollisionen entstehen) in eben ein und dem selben Verzeichnis liegen können.
Vorsicht, pitfall! Verzeichnisse mit sehr vielen Dateien können Performance-Probleme verursachen. Es ist üblich, die Dateien systematisch in Unterverzeichnisse zu verteilen, um solche Probleme auszuschliessen.
LG,
CK
Wenn die Dateien fortlaufend nummeriert werden, warum die Verzeichnisse dann nicht auch?
Weil es für den Verzeichnisnamen nicht notwendig ist. Sprechende Verzeichnisnamen sorgen somit auch für mehr Übersichtlichkeit. Uploadverzeichnisse liegen sowieso auch außerhalb der DocRoot, sind also nur für den Betreiber interessant.
Die Dateien jedoch kriegen gerade deswegen Nummern damit man über den Dateinamen einen manipulierten Verzeichniswechsel ausschließen kann. Und einen Index, egal ob als Datei oder DBlösung muss man sowieso anlegen, das ist auch der richtige Platz für den Originaldateinamen, die Länge und den ContentType, optional Checksum, mtime, ctime.
MFG
Hallo Felix,
um direkte Aufrufe über einen URL zu verhindern.
Das verhindert man am wirksamsten dadurch, dass man den Upload-Ordner per Konfiguration des Webservers für HTTP Zugriffe blockiert oder gleich außerhalb des Document Root platziert. Die regulären Zugriffe laufen sowieso über die erwähnte Zugriffsschicht. Eine großartige kryptographisch abgesicherte Namenstarnung ist dann nicht nötig.
Ob man die Uploadfiles auf Ordner verteilen muss, hängt vom Uploadvolumen und vor allem vom verwendeten Filesystem ab. Manche skalieren schlecht mit der Anzahl von Dateien, andere besser. Allerdings erkauft man das Verteilen auf Ordner ggf. damit, dass man nicht nur eine Datei lokalisieren und lesen muss, sondern zwei (ein Ordner ist - je nach FS - auch nur eine Art Datei). Man muss es testen.
Ob sich die Optimierung überhaupt lohnt, hängt vom Zugriffsvolumen der Seite ab. 100 Millionen Dateien, täglich tausende von Uploads und hunderttausende von Downloads? Ja, da lohnt sich der Hirnschmalz. 10000 Dateien, täglich 10 Uploads, 100 Downloads? Pfff, wurscht.
Rolf
Hallo Rolf,
Allerdings erkauft man das Verteilen auf Ordner ggf. damit, dass man nicht nur eine Datei lokalisieren und lesen muss, sondern zwei
Nö. Der Order-Name sollte sich aus dem Datensatz ergeben. Ein Beispiel für das, was ich meine: für die IDs von 1-10000 heißt der Ordner 1, für die IDs von 10000-20000 heißt der Ordner 2, usw. Da muss kein Lookup stattfinden.
10000 Dateien, täglich 10 Uploads, 100 Downloads? Pfff, wurscht.
Wenn ich über 10 Jahre 10 Uploads täglich habe, kommt da auch gut was zusammen 😉 Aber ja. Natürlich hängt das vom Volumen ab. Deshalb schrieb ich ja auch von „können“ und nicht von „werden“ und von einer Fallgrube, nicht von einem garantierten Problem.
LG,
CK
Für mein Fotoarchiv hat sich diese Verzeichnisstuktur nach Jahr und Monat:
├───2009
│ ├───07
│ └───08
├───2014
│ ├───01
│ ├───10
│ └───11
├───2015
│ ├───04
│ ├───05
bewährt wobei die Dateinamen nach dem Muster dd.mm.jjjj_xxx (xxx von 001..999) sind. Das Archivprogramm hab ich vor Jahren mal in c geschrieben. Mit Uploads die chronologisch einzuordnen sind würde ich genauso verfahren. MFG
Hallo pl,
so ein Programm habe ich auch. Es ist ein Windows Batchfile aus 16 Zeilen... 😉
Rolf
Hehe
ist doch geil, Kamera anschließen, einschalten, klick. 1991 hab ich meinen letzten Film entwickelt und Vergrößerungen angefertigt, Fotolabor: Küche, Bad.
Und was das Upload betrifft, da nutzen wir auf internationaler Ebene ein von mir entwickeltes Online-Dokumentenarchiv.
Das wollte ich erst mit legacy Submit bauen, hab das aber ganz schnell sein lassen. Mit der guten alten FileAPI jedoch ist die Anwendung sehr komfortabel geworden. MFG
Hello,
Für mein Fotoarchiv hat sich diese Verzeichnisstuktur nach Jahr und Monat:
├───2009 │ ├───07 │ └───08 ├───2014 │ ├───01 │ ├───10 │ └───11 ├───2015 │ ├───04 │ ├───05bewährt wobei die Dateinamen nach dem Muster
dd.mm.jjjj_xxx(xxx von 001..999) sind. Das Archivprogramm hab ich vor Jahren mal in c geschrieben. Mit Uploads die chronologisch einzuordnen sind würde ich genauso verfahren. MFG
Warum das Datum nicht in ANSI-Notation im Dateinamen und dann ein kurzes Statement zum Inhalt?
|YYYYMMDD_Garten_Datsche.png|
Glück Auf
Tom vom Berg
Es gibt halt verschiedene Möglichkeiten seine Daten über Ordnerstrukturen und Dateinamen zu organisieren. Und wenn man dann noch weiß was die Zahlen im Dateinamen bedeuten, kann das von Vorteil sein.
MFG
Hello,
Es gibt halt verschiedene Möglichkeiten seine Daten über Ordnerstrukturen und Dateinamen zu organisieren. Und wenn man dann noch weiß was die Zahlen im Dateinamen bedeuten, kann das von Vorteil sein.
Es geht um die Sinnhaftigkeit der Datennotation im jeweiligen Kontext.
Im Kontext üblicher Dateisysteme ist eine Notation nach dem Muster
dd.mm.jjjj_###, ### = lfd. Nummer
aus mehreren Gründen einfach nicht das Optimum - ganz im Gegenteil!
Ein wesentliches Nutzkriterium von üblichen Dateisystemen ist die sinnvolle SORTIERBARKEIT von Dateinamen. Diese Möglichkeit machst Du mit deiner Notation gleich doppelt kaputt. Und auch für den üblichen Index einer DB-Tabelle ist diese Notation des Dateinamens ungeeignet.
YYYYMMDD_###
wäre auch dafür besser geeignet.
Einzige Entschuldigung wäre, wenn die Tagesahl tatsächlich immer die höchste Wertigkeit haben sollte. Aber das könnte ich mir bestenfalls für den Wochentag vorstellen, frei nach dem Motto "was passiert immer freitags?".
Glück Auf
Tom vom Berg
Es kommt darauf an WAS Du vom Dateisystem nutzen willst. Wenn es nur dem Speichern dient sind die Dateinamen völlig Wurscht die müssen nur eindeutig sein!
Und gerade was Upload betrifft ist ein vom FS unabhängiger Index keine Kür sondern eine Pflicht. Weil das was zu Speichern (Beschreibung, mtime, ctime, ContentType..) ist über die Möglichkeiten die ein FS hierzu bietet weit hinausgeht.
Wer sich dessen nich klar ist kommt dann eben mit der Frage wie man den ContentType einer UploadDatei serverseitig feststellen kann Obwohl genau dieser ja beim Upload vom Browser mitgeliefert wird. Und wo bitte willst Du die Original mtime und ctime im Remote FS speichern? Oder eine Checksumme?
Genau aus diesem Grund wird eind Sortierfunktion des FS schonmal überhaupt nicht benötigt. Mit einem zweckmäßigen Index nämlich kann man sogar nach dem Autor einer Datei sortieren. Solche und ähnliche Anforderungen sind üblich. Nicht meiner Meinung nach sondern meiner Erfahrung nach!
MFG
Lieber pl,
Wer sich dessen nich klar ist kommt dann eben mit der Frage wie man den ContentType einer UploadDatei serverseitig feststellen kann Obwohl genau dieser ja beim Upload vom Browser mitgeliefert wird.
der kann unwahr sein! Daher muss man sich dahingehend sehr genau absichern! Wer sich dessen nich klar ist kommt dann eben im Zweifelsfall in Teufels Küche.
Liebe Grüße,
Felix Riesterer.
Wer sich dessen nich klar ist kommt dann eben mit der Frage wie man den ContentType einer UploadDatei serverseitig feststellen kann Obwohl genau dieser ja beim Upload vom Browser mitgeliefert wird.
der kann unwahr sein! Daher muss man sich dahingehend sehr genau absichern!
Dann zeig doch mal bitte wie Du das machst. Welche Erfahrungen hinsichtlich unwahr angegebener Contenttypes hast Du gemacht?
MFG
Hello,
Wer sich dessen nich klar ist kommt dann eben mit der Frage wie man den ContentType einer UploadDatei serverseitig feststellen kann Obwohl genau dieser ja beim Upload vom Browser mitgeliefert wird.
der kann unwahr sein! Daher muss man sich dahingehend sehr genau absichern!
Dann zeig doch mal bitte wie Du das machst. Welche Erfahrungen hinsichtlich unwahr angegebener Contenttypes hast Du gemacht?
Wie es unter Perl geht, weiß ich nicht. Wie es unter PHP geht, ist im Wiki beschrieben. Und darauf habe ich bereits ganz am Anfang des Threads hingewiesen.
Glück Auf
Tom vom Berg
Tom Du verstehst die Frage (die mit Perl gar nichts zu tun hat) nicht, ich stelle sie mal allgemein:
Welche Auswirkungen hat ein beim Upload falsch angegebener Content-Type? Bzw. mit welchen Auswirkungen muss man da rechnen?
MFG
Hello,
... dass einem jemand eine ausführbare Datei, eine Konfigurationsdatei (z. B. .htaccess) oder sonstige lästige Dinge hochlädt.
Aber das ist ja alles im Wikiartikel beschrieben. Die dort beschriebenen Fallstricke finden bestimmt auch ihre Pendants unter Perl, Python, oder sonstigen Server-Scriptsprachen.
Glück Auf
Tom vom Berg
Lieber pl,
Dann zeig doch mal bitte wie Du das machst.
in PHP setze ich den Content-Type auf application/octet-stream, wenn ich den Download-Dialog des Browsers erzwingen will. Wenn das der Server zum Client kann, kann das auch der Client zum Browser.
Welche Erfahrungen hinsichtlich unwahr angegebener Contenttypes hast Du gemacht?
Keine, denn dagegen hatte ich mich längst abgesichert.
Liebe Grüße,
Felix Riesterer.
Ja wir können das mal so sagen: Ein beim Upload falsch angegebener Content Type hat beim Upload keine Auswirkungen. Er spielt nämlich erst bei der Weiterverarbeitung eine Rolle. Z.B. wenn die Datei zum Download angeboten wird. MFG
Lieber pl,
Ja wir können das mal so sagen: Ein beim Upload falsch angegebener Content Type hat beim Upload keine Auswirkungen.
sicher? Wenn ich Dir ein PHP-Script als Bilddatei unterschieben kann, welches dann im Dateisystem abgelegt wird, dann ist das ein Sicherheitsrisiko. Klar kannst Du jetzt sagen, dass es in einem Bereich außerhalb von DOCUMENT_ROOT abgelegt werden muss, damit man es nicht über eine URL aufrufen kann, aber nicht alle Anbieter unterstützen bei ihren Webspaces einen solchen Bereich. Und dann ist noch die Frage, warum man ein so fälschlich unter geschobenes Script behalten und gar noch zum Download anbieten möchte, wenn es mit einem (warum eigentlich?) falschen Content-Type hochgeladen wurde. Ob sich Artikel-13-Uploadfilter daran verschlucken werden...?
Er spielt nämlich erst bei der Weiterverarbeitung eine Rolle. Z.B. wenn die Datei zum Download angeboten wird.
Ist das wirklich (immer) so?
Liebe Grüße,
Felix Riesterer.
Hello,
Er spielt nämlich erst bei der Weiterverarbeitung eine Rolle. Z.B. wenn die Datei zum Download angeboten wird.
... erst, wenn die Datei in den Focus des ausführenden Systems gerät. Das muss nicht unbedingt durch einen Request des Clients geschehen.
Ist das wirklich (immer) so?
Nein, definitiv nicht!
Ein simples Beispiel ist die ".htaccess"-Datei. Die muss/kann nicht explizit durch einen gezielten qualifizierten Request angesprochen werden, sondern würde dies auch implizit durch irgendeinen (http/s-)Request auf den Verzeichnisbaum, dem sie vorsteht.
Und ja! Ohne besondere Schutzmaßnahmen kann man eine .htaccess-Datei hochladen.
Glück Auf
Tom vom Berg
... erst, wenn die Datei in den Focus des ausführenden Systems gerät.
Das ist bei PHP Dateien immer der Fall wenn man seinen Webserver so konfiguriert hat daß er die parst.
Echt blöd, ne 😉
Hello,
... erst, wenn die Datei in den Focus des ausführenden Systems gerät.
Das ist bei PHP Dateien immer der Fall wenn man seinen Webserver so konfiguriert hat daß er die parst.
Seit wann parst PHP in der Standardeinstellung die .htaccess-Datei?
Glück Auf
Tom vom Berg
Der Webserver parst, wenn konfiguriert, PHP Dateien. Und zwar ohne Rückfrage 😉
PS: Achja, die .htaccess parst er auch wenns konfiguriert ist.
Lieber pl,
Der Webserver parst, wenn konfiguriert, PHP Dateien. Und zwar ohne Rückfrage 😉
ich fürchte, Du hast den Verlauf des Diskussionsfadens durcheinander gebracht.
In diesem Zusammenhang schreibst Du:
Weil das was zu Speichern (Beschreibung, mtime, ctime, ContentType..) ist über die Möglichkeiten die ein FS hierzu bietet weit hinausgeht.
Wer sich dessen nich klar ist kommt dann eben mit der Frage wie man den ContentType einer UploadDatei serverseitig feststellen kann Obwohl genau dieser ja beim Upload vom Browser mitgeliefert wird.
Mich stört Dein Satz über Browser und deren übertragene Content-Type-Angabe.
Du formulierst auf eine Weise, die impliziert, dass das niemals ein Problem sein könnte, weil auf diese Angabe Verlass sei. Sicherlich war das eine unglückliche Formulierung, denn ich unterstelle Dir einfach das Wissen darum, dass bei einem Request jeder Aspekt der übermittelten Daten manipuliert sein kann.
Später behauptest Du: Ein beim Upload falsch angegebener Content Type hat beim Upload keine Auswirkungen. Er spielt nämlich erst bei der Weiterverarbeitung eine Rolle. Z.B. wenn die Datei zum Download angeboten wird.
Diese auch wieder sehr kurze Aussage vermittelt schon wieder einen Standpunkt, den Du so wahrscheinlich eher nicht für Dich in Anspruch nimmst. Damit sagst Du nämlich aus, dass die Browser-Angabe zum Content-Type völlig unerheblich sei, so lange man die Datei einfach nur hochlädt. Auf dem System sei es herzlich egal, welchen Content-Type sie wirklich hätte. Erst dem User, der sie dann herunterlädt, könnte diese fehlerhafte Angabe Probleme bereiten. Hier erweiterst Du auf andere mögliche Fälle, in denen eine "Weiterverarbeitung" stattfindet. Leider schränkst Du dabei nicht ein, wer diese Weiterverarbeitung durchführt, oder wo.
Auf meine Nachfrage hin, wie Du das genau gemeint hättest, schreibst Du:
So isses: Die Angabe des Content-Type ist nicht verlässtlich! Von daher ist bei einer Verarbeitung stets der Inhalt zu prüfen und nicht der Content-Type.
Das gilt übrigens für jeden Request, der ja auch einen Content-Type sendet welcher die weitere Verarbeitung bestimmt.
Auch hier hältst Du Dich in Deinen Formulierungen wieder sehr kurz und implizierst damit, dass die Angabe des Content-Types aus dem Request (also Upload) direkt Auswirkungen auf "die weitere Verarbeitung" hätte. Damit bleibst Du schon wieder vage! Ich kann Dir vergewissern, dass ich beim Upload den Content-Type völlig ignoriere und die weitere Verarbeitung rein von den Inhalten der hochgeladenen Datei abhängig ist. Insofern ist Deine Formulierung für alle meine Fälle schlichtweg falsch.
.htaccess-Datei angesprochen, die unter falschem Content-Type durch den Upload-Prozess ins Dateisystem des Webservers zu liegen kommen könnte. Hier gibt es keine direkte weitere Verarbeitung. Der Apache wertet sie grundsätzlich aus, egal ob der Request diese Datei speziell referenziert, oder nicht. Es ist nun einmal die Standardkonfiguration, dass eine solche Datei auf der aktuellen Ebene im Dateisystem Webserverkonfigurationen enthalten kann. Und jetzt kommst Du (schon wieder sehr knapp formuliert) mit dem hier:Der Webserver parst, wenn konfiguriert, PHP Dateien. Und zwar ohne Rückfrage
Du wirfst hier Konfigurationsdateien des Webservers mit PHP-Scriptdateien in einen Topf. Das ist ein schlimmes technisches Faul!
Wenn Du richtig verstanden werden willst, dann musst Du ausführlicher formulieren. Das ist das Problem, das rein schriftliche Kommunikation mit sich bringt. Die Knappheit, in der Du formulierst, ist also ein Kommunikationsproblem.
Wenn Deine Argumente ernst genommen werden sollen, dann darfst Du nicht einfach Dein Fähnchen nach dem Wind hängen, sondern musst in Deiner Argumentationslinie klar gerade aus bleiben. Der Content-Type darf nicht erst bedeutungslos sein, um dann für die weitere Verarbeitung maßgeblich zu sein!
Liebe Grüße,
Felix Riesterer.
Hello,
Der Webserver parst, wenn konfiguriert, PHP Dateien. Und zwar ohne Rückfrage 😉
PS: Achja, die .htaccess parst er auch wenns konfiguriert ist.
Die wird üblicherweise auch unabhängig von der Scriptsprache berücksichtigt. Darum muss man eben dafür sorgen, dass User KEINE Dateien mif dieser Namensvorgabe hochladen können in das Reich der DocumentRoot. Ähnliches gilt für Gerätebezeichnungen etc.
Glück Auf
Tom vom Berg
So isses: Die Angabe des Content-Type ist nicht verlässtlich! Von daher ist bei einer Verarbeitung stets der Inhalt zu prüfen und nicht der Content-Type.
Das gilt übrigens für jeden Request, der ja auch einen Content-Type sendet welcher die weitere Verarbeitung bestimmt.
MFG
Lieber Marko,
Ansicht von der Option (ansehen...) ist ehr schlecht gelöst.
Du darfst den Link in einem neuen Fenster öffnen, dann hast Du nicht die Frickl-Ansicht.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
Du darfst den Link in einem neuen Fenster öffnen, dann hast Du nicht die Frickl-Ansicht.
ersetze „darfst“ durch „musst“. Die Beispiele sind ohne weiteres Wissen auf kleinem Bildschirm nicht nutzbar. Warum ist das Scrollen abgeschaltet?
Gruß
Jürgen
Lieber JürgenB,
ersetze „darfst“ durch „musst“. Die Beispiele sind ohne weiteres Wissen auf kleinem Bildschirm nicht nutzbar.
da sollte ich bei übermäßigem Freizeitvolumen einmal das JavaScript herauskramen und eine Messung der Viewport-Dimensionen vornehmen, um im Falle zu kleiner Maße direkt zum Beispiel weiter zu leiten. Also die Frickl-Ansicht sofort verlassen.
Warum ist das Scrollen abgeschaltet?
Im Hintergrund sollte die Seite wie gewohnt scrollen. Die Frickl-Ansicht selbst ist fix: #frickl { position: fixed; }
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
Warum ist das Scrollen abgeschaltet?
Im Hintergrund sollte die Seite wie gewohnt scrollen. Die Frickl-Ansicht selbst ist fix:
#frickl { position: fixed; }
warum denn das? Unter dem Frickl sieht doch sowieso nichts.
Ich fände es gut, wenn man auch auf Smartphones die Testmöglichkeiten des Frickls hätte. Und Scrollen würde da schon reichen.
Gruß
Jürgen
Lieber JürgenB,
warum denn das? Unter dem Frickl sieht doch sowieso nichts.
stimmt, auf dem kleinen Screen ist dann alles verdeckt.
Ich fände es gut, wenn man auch auf Smartphones die Testmöglichkeiten des Frickls hätte. Und Scrollen würde da schon reichen.
Wo positionierst Du dann die Elemente (<div id="frickl">...</div>) im Dokument? Von mir aus kann eine passende CSS-Direktive bei entsprechenden Viewport-Größen aus position:fixed auch ein position:static machen.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
warum denn das? Unter dem Frickl sieht doch sowieso nichts.
stimmt, auf dem kleinen Screen ist dann alles verdeckt.
auf großen aber auch.
Ich fände es gut, wenn man auch auf Smartphones die Testmöglichkeiten des Frickls hätte. Und Scrollen würde da schon reichen.
Wo positionierst Du dann die Elemente (
<div id="frickl">...</div>) im Dokument? Von mir aus kann eine passende CSS-Direktive bei entsprechenden Viewport-Größen ausposition:fixedauch einposition:staticmachen.
ich positioniere da gar nichts. Ich verwende das Frickl nur im Wiki.
Ich habe das gerade noch mal getestet. Im IOS-Safari ist das Frickel zu groß und wird nur teilweise angezeigt. Weder das ganze Frickl noch die Unterfenster lassen sich scrollen.
Anders im MacOS-Safari, da ist das Frickl-Fenster zwar auch fixiert, aber die Unterfenster lassen sich scrollen. Auch ist das Frickl-Fenster auch bei einem minimal kleinen Browserfenster noch ganz sichtbar.
Gruß
Jürgen
Hi,
Stellen wir uns mal folgende Aufgabe vor:
Multiple Upload soll möglich sein und zwar so, daß die Auswahl vor dem Absenden im Browser bearbeitet werden kann einschließlich einer Beschreibung und Thumbnail (falls img, pdf) für jede Datei.
Nach der Auswahl soll das Upload unbeaufsichtigt möglich sein mit Fortschrittanzeige und Statusreport für jede einzelne Datei
Beim Upload sollen mtime und size automatisch übertragen und ebenfalls serverseitig erfasst werden
Im Fehlerfall soll das Upload für die betreffende Datei wiederholt werden können ohne diese neu auswählen zu müssen
Auf derselben Seite sollen bisherige Uploads aufgelistet sein mit Möglichkeit zum Download entsprechend dem richtigen Content-Type, Löschmöglichkeit und das Bearbeiten der Beschreibung soll auch möglich sein.
Wie würdet Ihr sowas machen? Mit legacy multipart/form-data ist schonmal (3) gar nicht machbar!
Wie würdet Ihr sowas machen?
Mit Rolf-Rost-Mega-Fancy-Solutions. Natürlich.
Lieber pl,
Stellen wir uns mal folgende Aufgabe vor:
*gähn*
Wie würdet Ihr sowas machen? Mit legacy multipart/form-data ist schonmal (3) gar nicht machbar!
Dafür hat Moxiecode Plupload entwickelt. Anleitung gibt's auf der Upload-Seite... wenn man genügend weit liest.
Liebe Grüße,
Felix Riesterer.
gähn
Genau! FileAPI ist das Stichwort und die hat auch schon Jahre auf dem Buckel.