Beiträge von timtim

Hallo Katzemiau,

da wir nicht sehen können wie du das Element designed hast, aber die H Tags nutzen für den Zeilenumbruch / den Platz die Eigenschaften: display:block; und dann ein passendes margin, padding.

Ggf. reicht das schon.

https://www.w3schools.com/cssref/pr_class_display.asp

Grüße

Timo

Zitat von Arne Drews

Das ist zu einer Grundsatzdiskussion geworden, die glaube ich keinem etwas bringt.

Richtig, ich hab mich hinreisen lassen

Nur kurz noch den Nachtrag zur Second Order

Grüße und frohes entwickeln,

Timo

Zitat von basti1012

Der Php Entwickler der den hash erstellt ( erfunden und programmiert ) hat, könnte er den hash knacken ?

Hi Basti,

das das mit dem Hashen ist etwas anderes als verschlüsseln. Beim Verschlüsseln wird der Eigentliche Inhalt durch einen schlüssel so verändert das nur der den Schlüssel kennt, den Ursprungswert wieder Entschlüsseln / Lesen kann.

Einfaches beispiel: Cesar / Rot13 verschlüsselung (hier mal googeln)

Text ist ABCD  Rot13 rotiert einfach das Alphabet um 13 Zeichen  Damit ist dann A = N, B = O, C = P usw. 
Unser eispiel ABCD wird zu NOPQ. Wer den Schlüssel kennt (13) kann es zurückverwandeln. Du kannst den Schlüssel auch frei wählen
bei 1 wäre es A = B, C = D usw. 

Zum Hashen: lange zeit waren md5 und dann SAH1 ausreichend.

Das Hashen berechnet einen immer gleich langen wert aus den gegebenen Daten, dabei verliert man aber den Ursprungswert komplett. Die einfachste Hash-Funktion die mir als beispiel einfällt, ist das berechnen der Quersumme.

Bsp.: die Zahl 1234 hat die erste Quersumme 1+2+3+4 = 10 Zweite Quersumme 1+0 = 1. Damit wäre der Hash von 1234 = 1. Aber von 1 auf 1234 zu kommen ist unmöglich.

Das Quersummen beispiel zeigt aber auch, wo die Problematik von Hashs liegen, denn die Quersumme 1 hat auch die zahl 10, 100, 1000, 10000 usw.

md5 ist deshalb an einigen stellen unsicher geworden, weil wir mittlerweile so viel Rechenleistung haben, das man schnell nach neuen werten Suchen kann, die den gleichen Hashs haben. (Grund, md5 hat 32AlNum stellen, durch die Begrenzung haben wir schon mehr Daten die in Hashs umgewandelt werden können, als md5 platz bietet). Deswegen wurden hier neue Methoden entwickelt (die weit Komplexer sind um einen höchstmöglichen 'zufall' zu haben).

Daher ist die Frage ob auch der Entwickler das Knacken kann, zu verneinen, aber vor dem Entwickler muss man da auch keine Angst haben, da die Standards oder die Logik wie eine Verschlüsselung / Hash berechnet wird, "allen" bekannt ist, solange man genormte Methoden nutzt.

Die frage ist eher, haben die Entwickler von PHP Sicherheitslücken in ihrem Code und da kann man nur sagen, weiß man erst, wenn eine gefunden wurde. (Stichwort Hearthbleed).

Nochmal zur Sicherheit: Die Algorithmen dahinter sind Sicher, so lange wie das Zufällige berechnen zu lange dauert (man rechnet hier dann von 100/1000/10000 Jahren Rechenzeit).

Wenn wir Rot13 nehmen um den text zu entschlüsseln muss man den ganzen text bei einem Alphabet von 26 Zeichen, also nur 26 mal durchlaufen lassen um die Lösung zu finden. Bei den Quersummen mit einer stelle muss ich nur 10 (0-9) Kollisionen erzeugen, was Computer in Millisekunden schaffen. Mehr Komplexität = Mehr zeit = Mehr Sicherheit.

Hoffe das hilft,

Grüße

Timo

Dein Beispiel ist mir schon bewusst, aber da sind wieder injections möglich, weil das Prepare das nicht abfängt, deswegen brauchst du ja eine WhiteList und da kommt das escapen bzw. anderweitige validieren ins spiel, was du ja machst. *_real_escape_string wäre zum prüfen ebenfalls möglicht.

Zitat

Glaub mit - da draußen ist das das geringste Problem.

Sicherheit > "speed".

Ich weiß nicht wo dein da draußen ist, aber mein "da draußen" läuft über skalierbare Cloud Anwendungen, wir nutzen dort andere Technologien, und kein MySQL, und ja die Sicherheit ist wichtiger, aber die kommt an anderer stelle. Prepared Statements blockieren dir da ggf. andere Ressourcen und dann kommen Kosten hinzu. Das Prepared Statements auch kein QueryCaching erlauben ist ein anderes Thema. Hier nur der bezug auf deine Aussage Sicherheit > "speed" Ja, aber nicht über PreparedStatements weil der Sicherheitsaspekt zu den Prepared Statements kleiner ist als der Overhead.

Zitat

Aber Du kannst nicht alle Injections der Welt kennen.

Das, also das Thema Sicherheit, überlassen wir dem MySQL Server (bei richtiger Bediehnung).

Prepared Statements schützen nur vor first-order injections nicht second-order und wir überlassen lieber nicht dem SQL-Server die Sicherheit, wir überlassen ihm hier das richtige aufbereiten der Nutzdaten, wie auch dein beispiel zeigt.

Zitat

Ich hab mich lange damit beschäftigt.

Lange muss nicht richtig heißen. Pauschal aussagen bekommen pauschal antworten.

*Edit:

Ich hab das beispiel noch weiter angeschaut, du erstellt und änderst da auch nichts an der DB / Tabellen, was ebenfalls eine Anforderung war.

Grüße

Timo

Irgendwie fehlt mir hier die Betrachtungsweise wie Prepared-Statements funktionieren und das man die Wahl der Methodik abhängig von der Anforderung bauen sollte. Prepared Statements sind zu bevorzugen soweit ich überhaupt etwas Preparen kann und dabei sollte man auch prüfen, was das Prepared-Statement noch so macht bzw. welche Einschränkungen dahinter liegen.

Baue ich eine Middelware oder habe ein Setup bei dem ich nicht von vorne herein den aufbau der DB und oder den kommenden Input kenne, kann ich nicht mehr mit Prepared Statements arbeiten. d.h. immer wenn ich Dynamische Queries habe. Das gleiche gilt für Statements die außerhalb der CRUD Funktionalitäten liegen. Muss ich über Eingaben (egal ob vom User oder Konfigurationsdateien) die Datenbank modifizieren kann ich hier wieder keine Prepared Statements nutzen. Und hier gibt es auch für normale abfragen genügend beispiele bei denen PreparedStatements an ihre grenzen stoßen was die Parameter angeht oder mir fehlt irgendwo das wissen, wie ich z.B. vom User sowohl die abzufragenden Felder + dynamische wehre Bedingungen in ein Prepaid Statement setze. Oder ab einem bestimmten punkt bei dynamischen Queries dann doch der overhead von PreparedStatements zu Verschwendung von Ressourcen führt.

Hier bleibt eines der Werkzeuge zur Validierung der eingaben weiterhin z.B. das Escapen über *_real_escape_string.

Und ebenfalls verschleiert es für Anfänger die eigentliche Problematik: die Wichtigkeit der Validierung der eingaben. Man kann zwar statisch behaupten, "Nutze Prepared-Statements und deine Probleme sind gelöst" aber das wäre doch etwas naiv. Und auch aussagen "Nutze nie wieder eine Funktion/Modul xyz (obwohl sie noch supportet und nicht deprecated ist) wirkt auf mich auch eher als wolle man sich nicht mit der sache beschäftigen.

Ich beziehe mich hier auf die generelle Diskussion zu dem Thema OP sollte für die im Eingang genutzte frage am besten ein PreparedStatement nutzen.

Grüße

Timo

Hm, ich sehe gerade das ich mit dem oberen teil doch unrecht hatte.

Wenn es um das time out geht, hier wird ein eigener Prozess gestartet, welcher auch bei 0 Millisekunden immer noch länger braucht zum initialisieren als der aktuell laufende Programmcode. Normalerweise sollte man hier dann anfangen mit Promisses oder callbacks zu arbeiten.

Du kannst bei der IndexedDb aber auch mit await arbeiten, damit wartet dein Programm dann bis zum Ablauf. Wichtig ist, sobald du anfängst mit Asynchronen Prozessen zu arbeiten, musst du IMMER auf anderen Wege sicherstellen das die resourcen da sind auf die du wartest. In vielen Sprachen hast du dazu await, oder generell Promises auf die du warten kannst.

Der alte weg in JS war, bevor Promises und await kam, eine eigene timeout Funktion zu schreiben die wartet bis alle notwendigen Ressourcen da sind.

https://medium.com/@filipvitas…-async-await-3d047dddd313

Grüße

Timo

Gut, jetzt kommen wir in die Scope-hölle von JS, das Problem kann hier dennoch bleiben, das etwas anderes den Scope schließt, bzw. das der Aufruf der "onsuccess" irgendwo anders passiert.

Das ordentlich zu Debuggen ist nervig (Deswegen war die Idee durch einen eigenen definierten Scope wie eine Klasse das zu kapseln). Sagen wir du hast irgendwo ausersehen eine andere var db oder let db stehen und übersehen, dann könnte es sein, das dieses dein Scope überschreibt.

Oder du rufst die Funktion in einer anderen Funktion auf, welche dann wieder einen eigenen scope hat.

Aber um das raus zu finden müsste man den gesamten Code sehen :).

Grüße

Timo

Hier noch ein Nachtrag, weil ich nicht alle infos gegeben habe. Das es hier mit let nicht funktioniert hängt daran "wo" die Funktion aufgerufen wird.

Anders würde es funktionieren. Bsp:

let db
var test = {callback: function() { db = "testvalue"; console.log(db);}}
test.callback()
console.log(db) 

Hier funktioniert das auch mit let, weil der scope nach unten durchgegeben wird (aber nicht nach außen, wenn man let auch in der Funktion benutzt).

Bei deinem Code ist es zwar dennoch ein "let" Problem, liegt aber daran, das der Aufruf der Funktion an einer ganz anderen stelle passiert, in der der scope von let db; nicht mehr vorhanden ist.

Bei var sollte es funktionieren, weil var die variable in den globaln Scope (sprich, an das window objekt) hängt.

Nur noch als Nachtrag.

Grüße

Timo

Hi Stef,

ich würde dir hier empfehlen dir mal anzuschauen wie var, let und const in JS am sinnvollsten zu verwenden sind. var und let haben etwas mit dem Scope zu tun und let ist beschränkt auf den scope.

https://developer.mozilla.org/…/Reference/Statements/let

https://developer.mozilla.org/…/Reference/Statements/var

Generell würde ich dir empfehlen bei Skripten die bestimmte aufgaben erfüllen Klassen zu nutzen, da du den Scope hier viel einfacher handeln kannst. Wenn du ES6 nutzen kannst, dann kannst du die JS Klassen normal verwenden:

https://developer.mozilla.org/…aScript/Reference/Classes

Wenn du an ES5 gebunden bist, dann geht das auch, wird aber etwas anders geschrieben:

https://dev.to/_hridaysharma/u…ritance-in-javascript-n8d

(Oder du wechselst auf TypeScript und lässt das die generierung Händeln https://www.typescriptlang.org/)

Grüße

Timo

Hi openclimb,

"richtig" ist hier ja relativ, es kann auch sein das jene die er verwendet die richtige ist. Es kommt hier glaub stark auf die Versionen an die verwendet werden, aber da ich Kompozer nicht kannte und ich nicht wusste das Dreamweaver noch weiterentwickelt wird, habe ich bei einer kurzen suche nur gefunden, das die das Encoding wohl abhängig von Gerät usw. automatisch setzen. D.h. hier solltest du dich über die Software die du einsetzt schlau machen und wie man das einstellt und prüft.

Grüße

Timo

Hi,

wenn ich es richtig lese, es geht darum, bei der Erstellung der DB, diesen mit den MA zu befüllen. Es wird auch aufgerufen falls die DB noch nicht da ist. Wenn du bei dir die DB aus dem Browser löschst, geht das auch ein mal mit der 1. Danach ist das was in onupgrade passiert ja nicht nötig, deswegen sollte man auch prüfen "welche" version aufgerufen wird.

Daher geht es bei ihm, beim zweiten mal auch nicht mehr

Grüße

Timo

Hi,

das geht auch mit css alleine, mit dem "nth-child".

Bsp.:

Nimmt das zweite TR und davon das zweite TD.

tr:nth-child(2) td:nth-child(2) {
  background: red;
}

Grüße

Timo

Hi Stef,

onupgradeneeded ist dafür da, die Datenbank zu ändern, wenn die Version der DB sich geändert hat:

https://developer.mozilla.org/…DBRequest/onupgradeneeded

Vielleicht lese ich das falsch, aber du versuchst dort Daten in die DB zu schreiben oder? Du gibst ja oben immer Version 1 mit. Damit ist kein Upgrade notwendig. Das ist nicht zum schreiben der der Daten in die DB gedacht. Die Methode sollte ausgeführt werden wenn du z.B. Version 2 mitgibst. Aber gedacht ist das um die Datenbank selbst zu ungraden (neue Tabellen / Indexe hinzufügen).

Oder wird es auch beim erhöhen der DB-Version nicht ausgeführt? Dann müsste man wirklich mal schauen.

Grüße

Timo

Das ist richtig, mit der Formular version hättest du den vorteil das du das Formular bearbeitbar machen kannst um so verschiedene befehle zu senden. Wenn du es einfacher willst, dann würde ich Sempervivum 's Vorschlag befolgen. Und weiter das <a href='..'>An</a> nutzen. Mittels CSS kannst du das aussehen anpassen.

Grüße

Timo

Hi Private Very,

in dem Form wird nur das cmd geschickt, weil die parameter hier im form erwartet werden.

Ich würde dir daher empfehlen für jeden Parameter ein hidden input hinzuzufügen, schau dir das hier mal an:

https://www.w3schools.com/tags/att_form_method.asp

Damit solltest du dann zum gewünschten Ergebnis kommen.

Grüße

Timo

Hi,

mit VS-Code hat der $ nichts zu tun, das du hier vieles zusammenkopiert hast, habe ich schon vermutet.

Aber irgend einen Grund muss es doch haben das dort "id: tab" steht.

Die Frage ist, ob es wieder funktioniert wenn du den teil rauslöschst, das beste vorgehen ist dann, stück für stück die neuen teile wieder einzubauen bis es nicht mehr geht, oder andersrum, stück für stück Sachen ausbauen bis es wieder geht.

Meist liegt es daran das du JS-Fehler hast, die dazu führen das dein anderer Code nicht mehr ausgeführt werden kann. Da hilft es in Chrome in die Konsole zu schauen und dort erstmal alle Fehlermeldungen zu lösen.

Zu dem Variablen Problem, ich könnte jetzt sagen, mach aus dem tab erstmal einfach ein id: null, aber langfristig wird das dein problem nicht lösen :P.

Grüße

Timo

Gerne,

aber vue.js zu lernen lohnt auf jeden fall

Grüße

Timo

Hi,

ist das der gesamte code? Drei fehlerquellen finde ich auf anhieb.

Zeile 27: Du nutzt die variable tab ohne sie vorher irgendwo zu initialisieren.

Zeile 29: Du nutzt $, ich sehe aber nicht das du ein framework einbindest das $ verwendet (z.B. jquery, weil du unten auch nochmal $.post machst): Fehlt da das einbinden oder hast du das in Chrome mit offener Console entwickelt (Chrome bringt sein eigenes $ mit).

Zeile 29 nochmal: Ich finde kein element mit der klasse btn $('.btn') daher wird der teil eh nicht ausgeführt.

Aber die Fehler in den Zeilen können dazu führen das manche browser nichts mehr machen oder im beispiel von chrome wenn man die konsole beim laden offen hat, zumindest das einfügen der neuen reihen noch funktioniert.

Viele Grüße

Timo

Arne Drews Wenn ich das da oben richtig gelesen habe, ist das problem aktuell, das er nicht in das Submit-Event hinein geht. Damit kommt er ja nicht mal zu dem Punkt den du hier vorschlägst...

Aber damit ich da nichts falsch verstanden habe Nastypasty

Wenn du den

form.addEventListener('submit', async (e) => {
      e.preventDefault();
      const { setupIntent, error } = await stripe.handleCardSetup(   
          clientSecret, cardElement, {
              payment_method_data: {
                  billing_details: { name: cardHolderName.value }
              }
          }
      );
      if (error) {
          // Display "error.message" to the user...
          console.log(error.message);
      } else {
          // The card has been verified successfully...
          var hiddenInput = document.createElement('input');
          hiddenInput.setAttribute('type', 'hidden');
          hiddenInput.setAttribute('name', 'payment_method');
          hiddenInput.setAttribute('value', setupIntent.payment_method);
          form.appendChild(hiddenInput);
          // Submit the form
          form.submit();
      }
  });

mit

form.addEventListener('submit', (e) => {
    e.preventDefault();
    console.log("Inside Event");
  });

ersetzt, dann wird das console.log() nicht ausgeführt. Richtig?

Grüße

Timo

Ich kenne leider Lavarel nur vom namen und bei Vue.js bin ich auch nur etwas drin. Aber ggf. überschreibt hier etwas.

Aber wenn du sagst, das es außerhalb des Kontext läuft, dann würde ich nochmals versuchen einen code zu schreiben, der außerhalb deiner Anwendung richtig funktioniert und den hinein kopieren und schauen ob es noch läuft.

Ab dem punkt, müsstest du etwas tiefer in das JS-Debugging eintauchen :D. Gerade in Chrome über die Console bekommst du ja alle Informationen die irgenwie im Dom hängen, so z.B. auch die registrierten Event Listener.

https://developers.google.com/…c#geteventlistenersobject

Du kannst also über das Form Element einfach mal schauen, ob dein Event Listener noch gesetzt ist ab einem bestimmten Zeitpunkt.

Du kannst auch schauen ob dein Event funktioniert wenn du es im html direkt platzierst.

https://www.w3schools.com/tags/ev_onsubmit.asp

Ansonsten wüsste ich nicht wie ich hier direkt weiterhelfen kann.

Grüße

Timo