Kenne ich trotzdem nicht
Geht es Dir um ein mobiles Endgerät? Darauf habe ich XAMPP allerdings noch nie getestet.
Da müssen dann evtl. andere Leute was zu sagen.
Kenne ich trotzdem nicht
Geht es Dir um ein mobiles Endgerät? Darauf habe ich XAMPP allerdings noch nie getestet.
Da müssen dann evtl. andere Leute was zu sagen.
Ich habe ServersUltimate nie getestet, aber XAMPP macht denke ich mehr Sinn zum Testen, weil Dir dort alle notwendigen Server zur Verfügung stehen, die Du für eine Website mit Datenbankanbindung benötigst.
Der Connect sollte so wie dargestellt auch funktionieren. Du sagst aber leider nicht, welches Fehlerbild Du hast. Was passiert, statt dem, was Du erwartet hast? Kommt ein Fehler? ErrorReporting hochgeschraubt?
Persönlicher Tipp: Steig auf PDO um, damit kann man imho schöner arbeiten.
Wenn man PreparedStatements verwendet brauch man kein mysqli_real_escape_string
Richtig, man braucht es nicht zwingend, i.d.R. könnte das sogar kontraproduktiv sein.
Das gilt allerdings nur solange, wie Du als Entwickler den Aufbau Deiner Queries 100% unter Kontrolle hast. Arbeitest Du mit dynamisch generierten Queries, kann es durchaus sinnvoll und besser sein, eine escape_string Funktion einzusetzen.
Wenn man ohne PreparedStatements arbeitet ist mysqli_real_escape_string absolute Plicht ?
Auf jeden Fall empfehlenswert, ja.
Es wird häufig behauptet, beide Funktionen machen das selbe, das ist aber nur die halbe Wahrheit.
In der Kurzfassung kann man sagen: Eine escape_string Funktion versucht den kompletten String zu maskieren ( in den meisten Fällen also die komplette Query ), während sich die Prepared Statements "nur" um die Werte kümmern.
Daher ist es einfach falsch zu sagen: nutz es am besten nie wieder!
Wie man sieht und Du ja ehrlicher Weise zugegeben hast, verwirrt das die Leute, die dann denken, diese escape_string Funktionen seien veraltet o.ä.
PreparedStatements !== Escaping
Vergiss mysqli_real_escape_string. Die Funtion solltest Du nie wieder nutzen.
Das ist schlicht eine unbegründet falsche Aussage!
Wenn man sich mal den link aus #3 anschauen würde, dürfte die Frage, ob das Dreamweaver & Co. automatisch machen, selbst erklären.
Natürlich muss es über den localhost laufen. Ein http:// Aufruf routet natürlich ganz normal ins WWW.
Ich nutze zwar selten XAMPP, aber Du kannst in Deiner hosts Datei unter Windows einfach ne Domain als Alias für Deinen localhost setzen, dann kannst Du lokal testen, als wäre es online.
Was genau meinst Du denn? Verschachteln und CSS hat erstmal nichts miteinander zu tun.
Ich kann die Elemente verschachteln:
und trotzdem mit CCS drauf zugreifen:
wären die ersten Möglichkeiten, die mir adhoc einfallen.
Es gibt haufenweise Stellen, an denen das wichtig ist, hier mal eine kleine Übersicht: https://www.php-rocks.de/thema…ie-utf8-verschw-rung.html
.nth-child()
Auf den Viewport skalieren?!
Ich habe inzwischen gelesen dass der Rewrite nur funktioniert, wenn man einen VHOST über localhost anlegt!
Der localhost existiert als vhost automatisch, wenn Du XAMPP o.ä. verwendest.
Wenn Du natürlich lokal ohne Webserver arbeitest, geht es natürlich nicht.
Mein Hauptproblem ist das mein submit event, soweit ich das feststellen kann nicht funktioniert, da mein console.log() nie ausgeführt
Naja, soweit ich das sehe, ist die Ausgabe in der Konsole nur von einer Bedingung abhängig, das macht das Debugging relativ einfach!
error wird nicht gesetzt sein, lass Dir doch mal error vor der Bedingung ausgeben, nur so zum Spaß.
Da das vermutlich null, false oder undefined ergibt, schaut man sich die Stelle an, an error gesetzt werden müsste, also bei stripe.handleCardSetup.
Na, wer kommt drauf, was man sich dann wohl als nächstes anschauen sollte?
Und wenn da das erwartete raus kommt, kann man anfangen, die nachfolgenden Prozesse in Frage zu stellen.
Und wo ist dann in der search.php die Info, in welcher Quelle gesucht werden soll?
Die Frage ist mit den wenigen Informationen auch nur per Glückstreffer zu beantworten.
Niemand hier weiß, was für eine Community das ist und wie diese Quellen, in denen gesucht werden soll aufgebaut sind.
Weiterhin ist die Frage, ob es eine client- oder serverseitige Suche werden soll. Das macht gerade in Hinblick auf die Struktur einen riesen Unterschied.
Es geht ja nicht darum, dass man den key nicht auslesen kann
Ach so... Dann ist es Dir egal, dass ich mir den Key schnappen und den API Server mit ungewollten Calls über Deinen API-Key befeuere?
Dann würde ich die Seite am besten noch bekannter machen im Netz, damit es die böse Seite der Macht nicht so schwer hat, die Einladung zu übersehen.
Macht ihr euch eigentlich gar keine Gedanken zum Thema Sicherheit?!
Muss es alles in JavaScript sein?!
Ich würde einen vernünftigen Login schreiben und nur die relevanten Daten in einer Session halten.
Warum sollte ich Benutzer bezogene Daten in JS verwalten?
Wenn es Dir um die UX geht, kannst Du zum Laden von Inhalten ja XmlHttpRequest verwenden.
Die Steuerung über die verschiedenen Calls kann ich auch leicht über einen Parameter feuern, da benötige ich kein Array, das alle vorhält.
Kann man natürlich machen, aber besteht eigentlich kein Grund zu.
REST APIs sind i.d.R. immer ähnlich aufgebaut, der Aufruf erfolgt in ähnlicher Form, wie hier:
Die Daten für die Funktionen add und delete werden dann per POST übermittelt, häufig in Form von JSON.
Das alles würde ich aber PHP seitig machen und aus dem Client heraus nur die gewünschte Funktion und erforderlichen Daten übermitteln:
Auch hier wieder: Daten im POST.
Kein API-Key sichtbar!
Solange du aber JavaScript verwendest, kann ich Deinen API-Schlüssel auslesen aus der Website, vollkommen egal, wie Du den ablegst.
Dateisystem-Zugriffe sind zudem in JS immer noch experimentell, was aus Sicherheitsgründen auch gut ist. Und auf dem Sever kannst Du das nicht ablegen, weil JavaScript nativ da schon mal gar nicht rankommt ( wenn man Frameworks mal außer Acht lässt ).
API-Calls macht man Server seitig und gibt nur die Antworten zurück, die im Client relevant sind.
Noch sinnvoller wird's mit einer Datenbank dahinter.
Du willst den API-Key also im JavaScript öffentlich hinterlegen?!
Ich nutze cURL dafür.
Manche Logins sind allerdings clever und lassen das von außen nicht zu, den meisten ist es aber egal, da klappt das.
HTML-Seminar.de - mit Videos zum schnellen Lernen, wie man eine Website selbst erstellt.