Beiträge von SinnlosS

Zitat von Eudokya

2. abgehakt! (keine antwort erhalten)

Stimmt nicht, es sei denn du postest hier nicht den Code den du testest. Dein Script hat einen Parse Error, und zwar fehlt in der if-Bedingung zur Überprüfung von $_POST['3a'] das abschließende Semikolon.

Zitat von synaptic

nur mal so am rande.. wieso kommt dann nen access denied for user??

Das frage ich mich auch. Bei dem Code den er hier gepostet hat kommt Fatal error: Call to a member function query() on a non-object in...

Daher ja meine Vermutung, dass er geänderten Code hier gepostet hat, und nicht 1zu1 den der seine Fehlermeldung erzeugt.

Hab mir nur mal grad set_score angeschaut.

a) Das funktioniert so nicht, $this->table muß entweder konkateniert oder in geschweifte Klammern gesetzt werden:

// entweder so:
$rown = "SELECT ip FROM sterne where bericht = ".$this->table;
// oder:
$rown = "SELECT ip FROM sterne where bericht = {$this->table}";
// Damit hättest du schonmal ein funktionierendes Äquivalent zu dem was du geschrieben hast. Da ich aber mal davon ausgehe, dass in $this->table ein String steht, fehlen noch die einfachen Hochkommata:
$rown = "SELECT ip FROM sterne where bericht = '{$this->table}'";

b) Woher soll die Funktion set_score die Variable $conn kennen? Eigentlich müsste da eine Fehlermeldung kommen wie: Fatal error: Call to a member function query() on a non-object in
Es sei denn du hast hier gekürzten Code gepostet, was natürlich Hilfestellungen erschwert oder gar völlig unmöglich macht.

Ansonsten hatte Bandit ja schon geschrieben, dass $conn->close() rausmuss und hast du ja wohl auch schon entfernt.
Du solltest $conn als private Eigenschaft deiner Klasse anlegen, dann kannst du in set_score auch mit $this->conn auf die Verbindung zugreifen.
Und du solltest die Verbindung nicht in der Klasse herstellen, sondern im Programmcore und dann an den Konstruktor übergeben.
Selbst wenn du momentan ausschließlich in dieser Klasse eine DB-Verbindung benötigst, kannst du sicher sein, dass sich das nichtmal ändert? Außerdem verhindert es eine anpassungsfreie Wiederverwendbarkeit der Klasse für andere Projekte die bereits eine Datenbankverbindung bereitstellen.

Zitat von Nico1994

Hm stimmt daran hab ich nicht gedacht.

Ich könnte ja einfach den usernamen noch mit md5 oder sha1 verschlüsseln und die Zeichen, die aus der verschlüsselung entstehen sieht der User dann beim Link hinten dran.
Nur reicht es dann, auf der aktivierungs Seite den mit md5 verschlüsselten Usernamen mit dem Username aus der Datenbank zu vergleichen? Weil noch ne Tabelle macht das ganze wieder etwas aufwendiger

Das wäre nur unbedeutend besser. Es gilt das gleiche: Sobald jemand weiß, dass du bei der Aktivierung so vorgehst, kann er sich immernoch selber den md5/sha1 Hash aus seinem Usernamen erstellen und sich nach Belieben selber aktivieren.
Ich würde dir weiterhin zu meinem Vorschlag raten, so ein Aufwand ist eine zusätzliche Tabelle ja nun nicht. Und damit bist du auf der sicheren Seite.

Klar, das kannst du auch machen, dann nimmst du in meiner Beispiel-Abfrage einfach 'registriert' stattn 'geld_lastModified' und änderst das <-Zeichen in einer >-Zeichen.

Naja, wenn der Geldbetrag das einzige Kriterium ist, nach dem der Rang bestimmt wird, dann ist das so ja schon richtig. Dann haben Personen mit dem gleichen Geldbetrag auch den gleichen Rang. Wenn du ein weiteres Kriterium für den Rang hinzufügst kannst du das natürlich ändern, aber ein weiteres Kriterium brauchst du.
Eine Möglichkeit wäre zum Beispiel der Zeitpunkt seit wann derjenige diesen Geldbetrag hat als weiteres Sortier-Kriterium. Wenn also zwei Spieler 150,- EUR haben hat der Spieler den besseren Rang, der schon länger 150,- EUR besitzt.
Dafür müsstest du deine Tabelle `ht_user` um eine Spalte erweitern in der du bei jeder Änderung des Geldbetrags die aktuelle Zeit speicherst (z.B. `geld_lastModified`).
Die Abfrage könnte dann so aussehen:

SELECT 
  COUNT(*) AS anzahl 
FROM 
  ht_user 
WHERE 
  (
    geld>'{$user['geld']}' 
    OR 
    (
      geld='{$user['geld']}' 
      AND 
      geld_lastModified<'{$user['geld_lastModified']}'
    )
  ) 
  AND 
  gesperrt=0

Jap, genau so.
Und das mit allen in SQL-Statements verwendeten Daten die vom Client kommen.

Die Informationen die du lieferst reichen nicht aus um dir zu helfen.
Meine Glaskugel vermutet, dass die Homepage auf der veralteten php.ini-Einstellung register_globals=on beruht und auf dem neuen Webspace register_globals=off gesetzt ist, wie es auch sein soll.
Das ist aber reine Spekulation. Ohne die relevanten Code-Teile für die Generierung der Inhalte wird dir da niemand helfen können.

Ich nehme mal an, dass du mit dieser Aktivierung die email-Adresse als existierende Addy die auch dem Besucher der sich damit registriert gehört verfizieren willst. Da macht dein Vorgehen aber wenig Sinn.
Jeder User der einmal weiß wie die Aktivierung funktioniert, und dazu reicht ja ein Blick auf den zugeschickten Aktivierungslink, weiß sofort wie er sich mit mit beliebig vielen Fantasie-emails anmelden und direkt aktivieren kann.
Außerdem kannst du dann User nicht mehr über ein boolean-aktiviert-flag in der user-tabelle sperren, weil sie einfach nur den Aktivierungslink nochmal aufrufen müssen, und schon sind sie wieder aktiviert.

Du solltest dir lieber eine weitere Tabelle `user_aktivierung` (oder wie auch immer benannt) erstellen. Wenn sich ein neuer Benutzer registriert wird eine Zeile in die Tabelle geschrieben mit der id des neu angelegten Users (also dem primary key aus deiner usertabelle) und einem zufällig erstellten aktivierungscode.
Der Link der an den User verschickt wird sieht dann halt z.b. so aus: aktivierung.php?id=42&code=94a27815z46v2
Auf der aktivierung.php wird dann überprüft ob `user_aktivierung` einen Eintrag hat mit der user_id und dem aktivierungscode, falls ja wird der user aktiviert und der eintrag in `user_aktivierung` gelöscht.

Zitat von Santos

Für was genau ist dieses mysql_real_escape_string?

Wie bandit schon sagt -> Doku

Aber um mal ein kleines Beispiel zu bringen:
Nimm mal an ein, ein Besucher manipuliert seinen Cookie, so dass sein Benutzername auf auf einmal so aussieht: '; DROP DATABASE;
Wenn du das in deinen Query einsetzt sieht der so aus: SELECT passwort_hash,last_hit FROM ht_user WHERE username = ''; DROP DATABASE;
Könnte unerwünschte Auswirkungen haben.
mysql_real_escape_string sorgt dafür, dass entsprechende Zeichen ausreichend maskiert werden um sie gefahrlos in SQL-Statements benutzen zu können.
D.h. JEDER Wert der vom Client kommt (also alles aus POST, GET, COOKIE) soll IMMER mit mysql_real_escape_string entschärft werden, bevor der Wert in einem SQL-Statement verwendet wird.

Noch besser ist allerdings direkt mysqli oder pdo mit prepared Statements zu verwenden. Da wird das automatisch gemacht und du brauchst dich nicht mehr selber drum kümmern.

Zitat von Santos

Ich sehe darin keinen Vorteil für mich das Datum und die Zeit nicht als Unix-Timestamp zu speichern. Aber danke für deine Vorschläge

Der einzige Fall in dem es keinen Unterschied macht ist der, wenn du in deinen PHP-Skripten auch ausschließlich den Unix-Timestamp verwendest und nicht mehr in andere Datumsformate umwandelst. Aber selbst dann könntest du, wenn du z.b. datetime als Feldtyp verwendest, in deinem SELECT-Statement einfach schreiben SELECT UNIX_TIMESTAMP(`mein_datetime_feld`) ... und bekommst das gleiche Ergebnis.
Die SQL-Eigenen Feldtypen für Datum und Zeit zu verwenden hat zwei große Vorteile:
1. Die Lesbarkeit in der Datenbank. Wenn du in phpmyadmin direkt mal was nachschauen willst, mußt du einen UNIX-Timestamp erstmal umständlich umrechnen um ein lesbares Datum zu erhalten (es sei denn du bist irgendein überkrasses Rechengenie und machst das auf einen Blick).
2. Du kannst mit den Datumswerten direkt in deinem SQL-Statement schon wunderbar rechnen, alles ins passende Format bringen etc. Und das ist einiges schneller als die Berechnungen und Umformungen von PHP vornehmen zu lassen.
Ein Beispiel mal aus einem aktuellen Projekt von mir, bei dem ich gerne mal sehen würde wie das jemand in einer Abfrage ohne weiteren Programmcode umsetzt, wenn er seine Daten als Unix-Timestamp speichert:

SELECT 
				id,resource_id,title,value,isRegular,timeMin,timeMax 
			FROM 
				schedule__resource_content
			WHERE 
				job_id=? 
				AND
				(
					postDate=? 
					OR
					(
						endDate>=?
						AND
						(
							isRegular=1
							OR
							(DATE_FORMAT(postDate,'%w')=DATE_FORMAT(?,'%w') AND isRegular=2)
							OR
							(DATE_FORMAT(postDate,'%d')=DATE_FORMAT(?,'%d') AND isRegular=3)
						)
						AND
						id NOT IN (SELECT pk_content_id FROM schedule__resource_exception WHERE pk_exceptDate=?)
					)
				)
			ORDER BY
				resource_id,postDate,timeMin,title ASC

Es geht um die Ermittlung von Terminen an einem bestimmten Tag.
Diese stehen in der Tabelle `schedule__resource_content`.
Es gibt einmalige Termine (isRegular=0), tägliche Termine (isRegular=1), wöchentliche Termine (isRegular=2) und monatliche Termine (isRegular=3).
Mit dieser einen Abfrage hole ich mir für einen bestimmten Tag alle Termine ohne weitere Abfragen zu starten oder in PHP noch selektieren zu müssen.
Wie gesagt, das würde ich gerne mal sehen bei Speicherung des Datums als Unix-Timestamp (ich schließe nicht aus, dass es möglich ist, allerdings wüßte ich grad nicht wie und es wäre vermutlich etwas komplizierter und schlechter lesbar).

Wenn du nur Hobby-mäßig kleinere Webseiten ohne komplexere Funktionalitäten entwickelst, und auch keine weitergehenden Ambitionen hast was das Programmieren angeht, dann verwende ruhig weiter den Unix-Timestamp, die Performance-Unterschiede werden sich bei simplen Seiten mit durchschnittlichen Besucherzahlen nicht bemerkbar machen.
Falls du aber auf lange Sicht vorhast professioneller zu programmieren kann ich dir wirklich aus eigener Erfahrung raten so früh wie möglich solche Konventionen zu nutzen, denn sie machen durchaus Sinn. Und je mehr du dich an einen anderen Weg gewöhnst, desto schwerer wird es später sich das wieder abzugewöhnen.

Ich weiß, das ist ein Thema auf dem ich gerne rumreite, aber es wird halt so oft "falsch" gemacht. Und mir konnte bisher noch niemand einen klaren Vorteil bei der Verwendung des Unix-Timestamps gegenüber den Datums-Feldtypen von SQL nennen.

Arbeitest du mit mehreren verschiedenen DB-Verbindungen parallel? Sonst kannst du $resource auch einfach weglassen.

Edit: Da du dort mit $_COOKIE arbeitest und diese Werte vom Client kommen solltest du dringend mysql_real_escape_string verwenden.
Und was mir noch auffällt, du führst den Query der in $last_hit_sql steht nie aus.

Edit2: Achja, und Datum/Zeit sollte nich als Unix-Timestamp in der DB gespeichert werden. SQL stellt genügend passende Feldtypen dafür zu Verfügung, die eine Menge Vorteile bieten und keine Nachteile (von denen ich wüßte).

Mach dir erstmal um die nötigen Server-Kapazitäten Gedanken, wenn du eine Alternative zu google etc. bieten möchtest. Wenn du dafür das Geld hast reicht es sich auch noch für Programmierer aus.
Und wenn du keine ernsthafte Alternative zu Google etc. bieten möchtest, wozu dann?

http://ondra.zizka.cz/stranky/progra…tring_functions

Guck dir das mal an, vielleicht hilft dir das.

Das ist nur mit HTML nicht möglich, HTML ist statisch. Ohne PHP oder eine andere serverseitige Sprache ist das nicht möglich.

Es ist richtig, dass JavaScript keine wirklich relevante Sicherheitslücke darstellt.

Für die tatsächliche Verwendung auf öffentlichen Webseiten ist das aber leider völlig egal, weil da nur zählt was die Besucher denken, nicht was Fakt ist. Wenn jede Menge Leute der Meinung sind, dass Javascript eine gefährliche Sicherheitslücke darstellt und es dementsprechend deaktivieren (wie es übrigens auch heute noch leider in vielen Unternehmen Standard ist), dann bringt es dem Seitenanbieter nichts wenn er weiß, das JS nicht gefährlich ist. Wenn er deaktiviertes Javascript nicht berücksichtig bleiben trotzdem viele Leute ausgesperrt.

Ok, ich habe jetzt einen Weg der funktioniert, auch wenn mir immer noch nicht einleuchtet wieso es nicht so funktioniert, wie ich es oben probiert habe.

So hier klappt es aber:

var projectEndDate = '{$projectEndDate}';
		var projectEndDateSp = projectEndDate.split('-');
		var projectEndDateFormat = projectEndDateSp[0]+','+projectEndDateSp[1]+','+projectEndDateSp[2];
		$( "#datepicker" ).datepicker({ minDate:new Date(2010, 9, 23), maxDate: new Date(projectEndDateFormat) });

Ich da so ein kleines Problemchen mit dynamischen min-/maxDates im datepicker von JQuery.
Hier mal mein aktueller Stand und was ich probiert habe:

// Funktioniert einwandfrei:
$( "#datepicker" ).datepicker({ minDate:new Date(2010, 9, 23), maxDate: new Date("December 23, 2010 00:00:00")});


// Hier gibt mir das alert() das korrekte Datum aus
var projectEndDate = "{$projectEndDate|date_format:'%B %d, %Y 00:00:00'}";
alert(projectEndDate);  // gibt mir korrekt aus: December 23, 2010 00:00:00


// Und ab hier funktioniert es nicht mehr, es wird kein maxDate gesetzt:
var projectEndDate = "{$projectEndDate|date_format:'%B %d, %Y 00:00:00'}";
$( "#datepicker" ).datepicker({ minDate:new Date(2010, 9, 23), maxDate: new Date(projectEndDate)});


// Das hier funktioniert genausowenig:
$( "#datepicker" ).datepicker({ minDate:new Date(2010, 9, 23), maxDate: new Date({$projectEndDate|date_format:'%B %d, %Y 00:00:00'})});

Hat irgendjemand eine Idee wie ich das Datum aus der Smarty-Variable korrekt an new Date() übergebe? Mir will irgendwie grade nicht in den Kopf wieso das so nicht klappt

Zitat von Dodo

Mach dir doch einfach ein User-Stylesheet im Browser - damit solltest dus für dich anpassen können.

Ach lol, sowas geht?
Ich habe bisher immer alle Seiten "einfach so hingenommen".
Da werde ich gleich mal Onkel Google fragen wie ich das mache, danke für den Hinweis.

http://www.php-performance.de/kontrollstrukt…tch-ternaer.php

Guck mal an, hätte ich jetzt so nicht vermutet.

Nur mal so ne Idee, keine Ahnung ob andere das nicht vielleicht ganz anders sehen, aber ich fänds super wenn man dem Forum eine maximale Breite geben könnte, z.B. 1200 Pixel.

Grund:
Ich habe eine Auflösung von 1920x1080 und surfe im Vollbildmodus. Und da werden die Zeilen in den Postings schon seeehr lang, was das lesen leider erschwert.

Also es geht jetzt für mich keine Welt unter wenn das nicht klargeht, aber vielleicht findet der Vorschlag ja Anklang.