[PHP] BugReporter v0.1

[Florian Hämmerle]

Hallo alle zusammen!

Da ich im Moment gerade dabei bin, Lösungen für eine erfolgreiche Teamarbeit zu suchen, hab ich mich mal an den PHP-Editor gesetzt und angefangen zu tippen. Raus gekommen ist ein kleiner

BugReporter

Funktionen:

• BugReports erstellen
• BugReports editieren
• BugReports löschen
• Passwort nötig für diese Funktionen

Alles was für den BugReporter nötig ist, ist PHP und SQLite (ist bei neueren PHP-Versionen schon integriert).
Der BugReporter verwendet für zwei kleine Spielereien jQuery (ist aber für die Funktionalität nicht von Bedeutung).

Wer Lust hat, kann es sich ja mal anschauen. Ich hab vor, den BugReporter noch etwas auszubauen.
Was ich in nächster Zeit vorhabe:

• User-Handling einfügen (damit nicht immer die Passwort-Eingabe notwendig ist)
• Rollen für Team-Mitglied und Administrator
• BugReport-Status (offen, in Arbeit, Erledigt)
• Suche
• Erstell-Datum und Änderungs-Datum speichern
• RSS-Feed, damit man über Änderungen über dem laufenden bleibt (Alternative zu E-Mail-Benachrichtigung)
• Admin-Kontrollzentrum

Wer Ideen für weitere Features hat, bitte melden, ich werde versuchen, diese so weit wie möglich einzubauen.

Florian
alcaeus hat mich auf Sicherheitslücken aufmerksam gemacht. Ich werd diese erstmal ausmerzen und dann erst wieder einen Download anhängen.

[mirage228]

Muss ich SQLite noch zusätzlich installieren?

Derzeit bekomme ich lokal mit PHP 5.2 unter IIS 7.5 diese Meldung

Zitat:

Fatal error: Class 'SQLiteDatabase' not found in C:\inetpub\wwwroot\bugreporter\common.php on line 29

Edit: Ah, mit PHP 5.3 unter XAMPPLite geht es. Weitere Kommentare folgen :mrgreen:

Viele Grüße

[Florian Hämmerle]

ab PHP5 ist SQLite eigentlich standardmäßig dabei :S

Zitat:

SQLite ist, als Alternative zu MySQL, seit PHP 5.0 in PHP enthalten.

mfg Florian

[Florian Hämmerle]

Liegt es vielleicht daran, dass du XAMPPLite hast? Ich hab n "ordentliches" XAMPP bei mir auf dem Rechner und dort funktioniert es wunderbar.

Schöne Grüße,
Florian

[mirage228]

Mit XAMPPLite und PHP 5.3 habe ichs doch noch hinbekommen.

Also bisher gibt es ja noch nicht soo viel zu sehen, aber an sich wäre ich für mich persönlich auf jeden Fall an so einem einfachen Bugtracker interessiert, der nicht so komplex für kleinere Projekte ist, wie z.B. Mantis.

Was mich aber noch etwas verwirrt, dass beim Erstellen, Bearbeiten und Löschen-Dialog die Beschriftungen der Felder fehlen. Das sieht besonders beim Hinzufügen etwas seltsam aus... (Drei unterschiedlich große, leere Felder und ein Speichern-Button).

[Florian Hämmerle]

Zitat:

Zitat von mirage228 (Beitrag 1028539)

Mit XAMPPLite und PHP 5.3 habe ichs doch noch hinbekommen.

Also bisher gibt es ja noch nicht soo viel zu sehen, aber an sich wäre ich für mich persönlich auf jeden Fall an so einem einfachen Bugtracker interessiert, der nicht so komplex für kleinere Projekte ist, wie z.B. Mantis.

Was mich aber noch etwas verwirrt, dass beim Erstellen, Bearbeiten und Löschen-Dialog die Beschriftungen der Felder fehlen. Das sieht besonders beim Hinzufügen etwas seltsam aus... (Drei unterschiedlich große, leere Felder und ein Speichern-Button).

Ja das war auch mein Antrieb, einen eigenen kleinen zu schreiben.
Beschriftung der Felder werd ich noch hinzufügen. *work* werd den Anhang sofort mit dem neuen ersetzen.

mfg Florian

[mirage228]

Ah gut, das bringt schon mal etwas Licht ins Dunkel.

Damit sich Dein BugReporter aber noch etwas mehr als solcher bezeichnen kann, fände ich folgende Funktionen wichtig:

• Bug-Status (wie schon oben von Dir angemerkt)
• Datum des Bug-Reports, damit ich solche ggf. chronologisch abarbeiten kann
• User-Handling (wie auch von Dir schon genannt), damit auch Benutzer / Gäste ggf. Bug-Reports einstellen können
• Zu letzterem: E-Mail Benachrichtigung bei neuem Bug-Report von User

Und noch zwei Details zur Oberfläche:

• Im Löschen-Dialog wird nur von "diesem" Bugreport gesprochen. Wenn man nicht gerade auf die ID in der Adressleiste achtet, weiß man nicht unbedingt was man gerade löscht
• Beim Bearbeiten / Hinzufügen / Löschen - Dialog fehlt jeweils Header und Footer der Seite

Viele Grüße

[Florian Hämmerle]

Danke für die Hinweise.

Header und Footer hab ich da bisher extra weggelassen, aber hat schon seine Berechtigung, falls man mal auf die Seite gerät ohne dass man es eigentlich will. Werd ich in den kommenden Tagen noch erledigen.
Zu den anderen Hinweisen:

• E-Mail-Benachrichtigung: Ist sicher ein nettes Feature, aber für einen kleinen BugReporter wie ich ihn machen will glaub ich nicht nötig. Dann mach ich da glaub ich lieber ein RSS-Feed, dass Interessierte dann abonnieren können.
• User-Handling: Ich hab mir das so vorgestellt, dass sich Mitglieder registrieren können und vom Administrator freigeschalten werden müssen. Dann können sie direkt BugReports verfassen und editieren. Löschen kann nur der Administrator (kann auch mehrere Administratoren geben). Gäste können auch BugReports verfassen, diese müssen aber noch von einem Mitglied oder Administrator freigeschalten werden (in der Zwischenzeit, also von der Erstellung bis zur Freischaltung, sind sie als 'nicht-sicher' markiert.). Um aber nicht von irgendwelchen Bots heimgesucht zu werden, wird dann auch für Gäste eine "are you human?"-Abfrage nötig werden.
• Datum des Bug-Reports: werd ich auch noch einbauen --> date_create, date_edit, dann hat man beide Datum für die Suche.
• Für die leichtere Handhabung des ganzen (falls es mal mehrere BugReports werden ist es sehr umständlich jeden einzeln zu löschen) werd ich dann auch ein Administrator-Kontrollzentrum bauen, in dem man eine Liste der BugReports hat, und dort schnell mehrere gleichzeitig als erledigt markieren kann oder löschen.

Danke erstmal fürs Testen,
Florian

[alcaeus]

Ganz kurz und buendig: SQL-Injection. In 5 deiner 4 Datenbank-Funktionen. Das ist das kritische.
Dazu kommt: die Anwendung ist ohne technische Ueberlegung aufgebaut. Nach ein paar zusaetzlichen Features hast du 200 PHP-Dateien, wovon 10 functions_* heissen und mindestens 30 Funktionen enthalten. Wie willst du da noch den Ueberblick behalten?
Weitere Punkte: Templating-System ist nicht nur nicht vorhanden, sondern auch sehr ungeschickt geloest (wenn du die HTML-Ausgabe im PHP-Code zusammenstellst kannst du dort auch die PHP-Tags schliessen und den HTML-Code direkt hinschreiben. Datenbanktechnisch bist du voll auf SQLite fixiert. Die Verwendung eines Abstraction Layer (PDO) laesst dich da unabhaengiger sein und verringert das Risiko solcher brachialer Sicherheitsluecken (Prepared Statements).

Wenn du ernsthafte PHP-Anwendungen entwickeln willst, vergiss den Ansatz den du getroffen hast. Mach dich uebers MVC-Konzept schlau, informier dich ueber diverse MVC-Frameworks und guck mal was die fuer dich machen koennen. Mein Favorit ist immer noch Symfony 1.4 mit Doctrine. Da wird das Ganze schon etwas interessanter: Datenbank-Abstraktion, klare Trennung von Logik und View, Logik in Models gekapselt, ein Test-Framework fuer Unittests, usw.

Nimms mir nicht uebel, aber ich wuerde dir dringends raten, den Download aus dem ersten Beitrag erstmal wegzunehmen und nochmal ueber die Applikation nachdenken.

Greetz
alcaeus

[Florian Hämmerle]

Ich hab nicht vor, das Ding groß zu machen. Es ist eigentlich nur für mich gedacht. Wer es brauchen kann, kann es sich gerne ziehen und damit machen was er will. Speziell für dich: kannst es gerne runterladen, entpacken und in den Papierkorb verschieben.

Ich hab auch nie gesagt, dass der Code absolut sicher ist, oder sich an irgendwelche Styleguides hält. Was PDO anbelangt: Ich hab mich für SQLite entschieden, weil es eben sehr einfach gehalten sein soll. Es kann auch sein, dass ich an der Struktur, wie sie jetzt ist, nochmal alles ändere. Es geht mir nicht darum nen perfekten BugReporter zu basteln, sondern etwas kleines, was ich brauchen kann. Ob es jemals noch wer anderer verwendet ist mir eigentlich egal.

Und wenn ich ernsthaft PHP-Applications schreiben möchte, würde ich mich nicht in nem DELPHI-forum sondern in nem PHP-Forum melden ;).

Schöne Grüße,
Florian

PS: Trotzdem werd ich mir deine Hinweise (SQL Injection, Templates, etc) zu Herzen nehmen.

[alcaeus]

Moin,

Zitat:

Zitat von Florian Hämmerle (Beitrag 1028581)

Ich hab auch nie gesagt, dass der Code absolut sicher ist, oder sich an irgendwelche Styleguides hält.

Styleguides sind nebensaechlich. Sie sind zwar auch wichtig, aber tun momentan nichts zur Sache. Mir ist schon klar dass du nicht gesagt hast, dass der Code sicher ist, aber wenn man Anwendungen veroeffentlicht dann sollte man vielleicht drauf achten, dass da keine solche Loecher drin sind. Hier sprechen wir nicht von einem "Och, unter bestimmten Umstaenden klappt das Loeschen nicht" sondern "Man kann wahlfrei Queries ausfuehren". Was dich rettet ist hier SQLite (dazu gleich noch mehr), weils da eine Datenbank gibt. Ansonsten koennte ich anfangen mit "DROP DATABASE <irgendwas>" oder eben manipulierten Queries um Daten auszulesen.

Zitat:

Zitat von Florian Hämmerle (Beitrag 1028581)

Was PDO anbelangt: Ich hab mich für SQLite entschieden, weil es eben sehr einfach gehalten sein soll. Es kann auch sein, dass ich an der Struktur, wie sie jetzt ist, nochmal alles ändere.

es spricht nichts gegen die Wahl von SQLite. Du kannst auch ueber PDO SQLite ansprechen - der Vorteil ist lediglich dass du ohne grosse Aenderungen auch zu anderen Datenbanken sprechen kannst. Das ist lediglich die Frage des Connection-Strings. PDO uebernimmt fuer dich die Kommunikation mit dem jeweiligen DBMS, du musst dich nur um die Daten und Queries kuemmern.

Zitat:

Zitat von Florian Hämmerle (Beitrag 1028581)

Es geht mir nicht darum nen perfekten BugReporter zu basteln, sondern etwas kleines, was ich brauchen kann. Ob es jemals noch wer anderer verwendet ist mir eigentlich egal.

Das mag durchaus sein, aber wie oben erwaehnt: wenn du Software veroeffentlichst, sollte ein Grundniveau vorhanden sein - sowohl was die Stabilitaet anbelangt als auch die Sicherheit.

Zitat:

Zitat von Florian Hämmerle (Beitrag 1028581)

Und wenn ich ernsthaft PHP-Applications schreiben möchte, würde ich mich nicht in nem DELPHI-forum sondern in nem PHP-Forum melden ;).

Es spricht nichts dagegen, hier Fragen zu stellen. Du waerst nicht der Erste der das macht und es gibt hier doch einige die sich im PHP-Bereich gut auskennen.

Greetz
alcaeus

[Florian Hämmerle]

Hab die Struktur mal etwas abgeändert. Ich hab jetzt sowas wie Templates (eins für den Header, eins für den Footer und welche für die verschiedenen Seiten). Darin sind ab und zu die eine oder andere PHP-Anweisung enthalten (Ein Template kann auch andere Templates einbinden). Die Daten dafür werden in nem Array übergeben und das Template bindet diese dann je nach Bedarf ein. Für sowas kleines wie das Tool möchte ich nicht auf Smarty oder ne andere Template-Engine zurückgreifen (vielleicht mach ich es trotzdem noch, aber bisher ist es noch nicht geplant). Weiters hab ich jetzt nur noch 1-2 Dateien, die die ganzen Aufgaben annehmen und je nach Parameter andere Funktionen ausführen.

Auch hab ich jetzt mal etwas in Richtung Session-Verwaltung gemacht, d.h. man muss sich nicht mehr jedes mal anmelden, wenn man etwas an den Reports ändert sondern einmaliges Anmelden reicht aus, danach wird mit der Session eine ID weitergegeben, die auf Gültigkeit überprüft wird.
Als nächstes möchte ich die DB-Abfragen mit escape_string sicherer machen.

Dann darfst du dir das ganze gerne nochmal ansehen und wieder deine Kommentare zu Sicherheit, etc. abgeben. Ich werd versuchen, sie zu beachten.
Was PDO oder SQLite angeht: Ich werd bei SQLite bleiben. Ist automatisch bei PHP bei. Ist wie mit Fremdkomponenten in Delphi. Mag ich nicht, weil man da noch zusätzliche Sachen installieren muss, die man ansonsten nicht braucht.

mfg Florian