Hallo allerseits,
Wieder mal was neues für EleLa (Elektronik Lagerverwaltung), hier der
Start der PHP-Version. Somit könnte EleLa auch über ein Web Browser
bedient werden.
Nur mal ganz langsam, ich habe hier jetzt keine fertige Web-Applikation
für EleLa fertig gestellt, sondern nur das mal angefangen, den
Grundstein gelegt.
Die Dateien sind frei verwendbar und erweiterbar, also jeder der sich
mit PHP/HTML aus kennt darf gerne weiter programmieren.
Ich selbst bin kein PHP Experte, daher der Aufruf an die EleLa Gemeine
hier an dem Projekt weiter zu Arbeiten. Das ganze ist jetzt seit 2 Tagen
entstanden und meine aller erste PHP-Erfahrung.
Diese aller erste Version bietet erst mal nur das Grundgerüst und man
kann einige Daten anschauen.
Die Datei:
index.php ist die Start-Datei, die muss bei Apache eingetragen werden
config.php die Verbindungsparameter zur MySQL Datenbank sowie globale
Funktionen
config.css Stylesheet
tabtop.php Überschrift-Zeile um auf andere Seiten zu kommen
Die restlichen Dateien sollten je nach EleLa Ansicht selbsterklärend
sein.
Man könnte dafür auch ein SVN über dieses Forum einrichten. Ich möchte
das erst dann machen wenn sich jemand hierfür interessiert zu
programmieren.
Nun ja, es ist ein Anfang.
Hier der Link zum EleLa Thread mit der EXE für Windows/Linux:
Beitrag "EleLa - Elektronik Lagerverwaltung"
Mit mehr Beschreibungen und der Einrichtung der Datenbank.
Ich wei ja nicht.
Ich hab damals so ein schönes Framework angefangen, mit
vollparametrischer Suche, Darstellung über XML/XSLT und so weiter.
Bisher hat da niemand dran weitergemacht :-}
Hier:
Beitrag "Re: Teile-Verwaltung für elektronische Bauteile"
Im Anhang zwei Bildschirmphotos davon.
Sehr gute Idee!
Das macht auch den Zugriff im firmeninternen Netz einfacher -
plattformübergreifend ist es dann sowieso.
Und PHP beherrschen wir hier auch, können also einen (kleinen) Teil
beisteuern.
Chris D.
Und zu den PHP-Quellen:
Alle Achtung davor, binnen zwei Tagen bereits so weit eingestiegen zu
sein!
Nichtsdestotrotz: Ich (Achtung, persönliche Meinung!) würde nicht mehr
auf PHP setzen -- PHP vegetiert in bahnbrechender Konzeptlosigkeit und
Redundanz vor sich dahin. Hunderte Baustellen, doppelte Interfaces, die
alle mal die anderen ablösen sollten und so weiter. Dafür kannst du
natürlich nix.
Wofür du aber was kannst: Es fehlen halt doch noch ein wenig Erfahrung
:-)
. Datenbank: Verpack die in eine abstrakte Klasse.
. Benutzer-E/A: Vorsicht bei Benutzereingaben und Ausgaben! HTML
maskieren!
@Sven P. (haku)
EleLa/PHP hat nun mal den Riesen Vorteil, dass es bereits seit über
einem Jahr eine vollständig gut funktionierende EXE gibt, die nicht nur
Bauteile sondern auch Projekte, Historie/Logbuch und vieles mehr
verwalten kann.
Dieses PHP/Web-Interface ist nur die logische Erweiterungsstufe um mehr
Mobil zu sein, z.B. Netbook mit Android oder die ganzen Mini-Tablets wo
es heutzutage gibt.
@Chris D. (myfairtux)
Ich würde mich sehr freuen!
Markus Müller schrieb:> Dieses PHP/Web-Interface ist nur die logische Erweiterungsstufe um mehr> Mobil zu sein, z.B. Netbook mit Android oder die ganzen Mini-Tablets wo> es heutzutage gibt.
Nein, ist es ja leider nicht. Es wird auf kurz über lang die vollständig
redundante Umsetzung des Binaries werden. Du musst ja doch die ganze
Programmlogik wieder in PHP nachprogrammieren, wenn du die
Webschnittstelle nicht nur als 'nur zum Angucken' haben möchtest.
Du hast am Ende zwei vollkommen verschiedene Projektstämme, die du
getrennt pflegen musst: Baust du im Binary was neues ein, musst du PHP
hinterherentwickeln und umgekehrt. Das bündelt dann unnötig
Arbeitskraft, was immer schade ist. Durfte ich auch schon erleben, darum
sieh es als vorsichtige Warnung.
Ich hätte meinen PHP-Krams auch gerne weitergetrieben. Aber mir hats die
Lust an Webprogrammierung/PHP gründlich verdorben.
Ich habe mir sehr sehr lange überlegt ob ich nicht eine EXE als
Internetserver baue, auf die dann die Clients zugreifen oder ob ich PHP
verwenden sollte.
PHP hat den Vorteil dass es auf Providern im Internet geht, die EXE geht
da nicht. Somit fiel die Entscheidung auf PHP.
Wegen:
>. Datenbank: Verpack die in eine abstrakte Klasse.
Ich habe jetzt noch keine Ahnung von Klassen, aber die ganzen
Datenbank-Aufrufe habe ich schon ausgelagert, so dass man die Befehle je
nach Datenbanktyp (MySQL/PostgreSQL) umschalten könnte, siehe z.B.
1
// Query-Abfrage ausführen
2
function MyQuery($SQL)
3
{
4
global $P_DBTyp;
5
if ($P_DBTyp == "MySQL")
6
{
7
$Query = mysql_query($SQL);
8
} else die ("Datenbanktyp $P_DBTyp wird nicht unterstützt");
Sven P. schrieb:> Du hast am Ende zwei vollkommen verschiedene Projektstämme, die du> getrennt pflegen musst: Baust du im Binary was neues ein, musst du PHP> hinterherentwickeln und umgekehrt. Das bündelt dann unnötig> Arbeitskraft, was immer schade ist. Durfte ich auch schon erleben, darum> sieh es als vorsichtige Warnung.>> Ich hätte meinen PHP-Krams auch gerne weitergetrieben. Aber mir hats die> Lust an Webprogrammierung/PHP gründlich verdorben.
Ja, die doppelte Pflege ist ein Problem. Wobei wenn die ein oder andere
Funktion über Web nicht verfügbar ist, darin sehe ich jetzt noch kein
Problem. Ich denke, es ist am wichtigsten, dass wenn man unterwegs ist,
dass man den Bestand mal für ein bestimmtes Bauteil überprüfen kann.
Also man sitzt grad bei einem Kumpel und diskutiert über eine neue
Schaltung oder so.
Wenn nicht PHP, was für eine Sprache hättest du stattdessen verwendet?
Noch kann man problemlos wechseln, die 2 Tage sind ja fast nichts und
das ganze sind sicher mehrere Mann-Monate Arbeit.
Markus Müller schrieb:> Ich habe mir sehr sehr lange überlegt ob ich nicht eine EXE als> Internetserver baue, auf die dann die Clients zugreifen oder ob ich PHP> verwenden sollte.
Offen gestanden, sind das beides miserable Ideen :-/
In erster Variante erfindest du den HTTP-Server neu, mitsamt
Sicherheitslücken. Warum? Greif doch lieber auf gut ausgetestete Server
zurück.
Und die andere Variante, naja. PHP halt :-}
> PHP hat den Vorteil dass es auf Providern im Internet geht, die EXE geht> da nicht. Somit fiel die Entscheidung auf PHP.
Die Gründe sind mir geläufig, habe mich immerhin einige Jahre damit
herumgeschlagen.
Beweggrund für mein Projekt war eigentlich, einen zentralen Server
aufzusetzen. Ich habe alles so programmiert, dass es mehrbenutzerfähig
ist. Die Benutzer sollten dann z.B. in der Lage sein, Bauteilangebote zu
inserieren, zwecks Such&Find bzw. Bauteiltausch.
> Wegen:>>. Datenbank: Verpack die in eine abstrakte Klasse.> Ich habe jetzt noch keine Ahnung von Klassen, aber die ganzen> Datenbank-Aufrufe habe ich schon ausgelagert, so dass man die Befehle je> nach Datenbanktyp (MySQL/PostgreSQL) umschalten könnte, siehe z.B.>
1
// Query-Abfrage ausführen
2
> function MyQuery($SQL)
3
> {
4
> global $P_DBTyp;
5
> if ($P_DBTyp == "MySQL")
6
> {
7
> $Query = mysql_query($SQL);
8
> } else die ("Datenbanktyp $P_DBTyp wird nicht unterstützt");
9
> return $Query;
10
> };
Ja, genau das sollst du nicht machen. Du produzierst redundanten
Quelltext in rauhen Massen (if, if, if...).
Schau dir doch z.B. mal phpBB an, dort hat man das mit Klassen gelöst.
Oder Benutz halt Klassen aus der PHP-Klassenbibliothek, dafür sind die
doch da...
>>. Benutzer-E/A> Sind ja noch keine drin ;-)
Markus Müller schrieb:> Ja, die doppelte Pflege ist ein Problem. Wobei wenn die ein oder andere> Funktion über Web nicht verfügbar ist, darin sehe ich jetzt noch kein> Problem.
Ich habe dich gewarnt :-)
> Ich denke, es ist am wichtigsten, dass wenn man unterwegs ist,> dass man den Bestand mal für ein bestimmtes Bauteil überprüfen kann.> Also man sitzt grad bei einem Kumpel und diskutiert über eine neue> Schaltung oder so.
Hast du mal darüber nachgedacht, ob man auf so einen
MySQL-Datenbankserver überhaupt von extern zugreifen kann?
Ziemlich viele Webhoster erlauben nämlich nur Zugriffe vom Server selbst
('localhost'), aus Sicherheitsgründen. Dann würde dein PHP zwar laufen,
aber die EleLa könnte nicht darauf zugreifen.
> Wenn nicht PHP, was für eine Sprache hättest du stattdessen verwendet?> Noch kann man problemlos wechseln, die 2 Tage sind ja fast nichts und> das ganze sind sicher mehrere Mann-Monate Arbeit.
Ich weiß es einfach nicht, darum bin ich so sehr blockiert, was
Webprogrammierung angeht.
Für den HTML-Kram habe ich mit XML und XSLT sehr gute Erfahrung gemacht
-- das funktioniert besser, als jedes Template-System (Smarty,
FastTemplate...). Aber als Skriptsprache selbst... tja. PHP ist von
allen noch am C-ähnlichsten, was mir persönlich gefällt. Das war es aber
auch schon -- guck dir nur mal den Namensraum an. Ansonsten, Python
vielleicht, oder Ruby(-on-Rails). Dieses Forum hier ist m.W.n. in Ruby
programmiert.
Kennst Du EleLa, ich meine die Windows oder Linux-Version? Damit
könntest Du etwa abschätzen, dass viele Dinge fast unmöglich sind die in
PHP rein zu bekommen.
Ruby hat schon eine sehr spezielle Syntax.
Python ist schon einfacher.
Ja, Provider bieten selbst kaum eine Möglichkeit der direkten Anbindung
der Datenbank. Firmen/Privatpersonen hingegen lassen den MySQL Server /
PHP zu Hause laufen und stellen über DynDNS einen Zugriff auf die Seite
bereit. Damit braucht es auch keinen Provider dafür muss der eigene
"Server" immer an sein.
Es kommt hier auf die Leute drauf an, mit welcher Sprache die am
liebsten programmieren würden.
Ja, kenne ich. Und nein, ich wüsste nicht, was da so unmöglich dran sein
dürfte.
Delphi hat in meinen Augen auch eine sehr spezielle Syntax :-)
PHP indes auch. Guck dir doch nur mal ein paar Seiten Dokumentation zu
OOP an. Du wirst feststellen, dass die nur vor Ausnahmen,
Sonderregelungen für Rückwärtskompatibilität, dann doch wieder
tiefgreifenden Änderungen gegenüber früheren Versionen und Unterschieden
zum OOP in C++ strotzen. Gerade letzteres ist ungemein gefährlich, wenn
man nebenher eben C++ programmiert.
Ich will dich beim besten Willen nicht daran hindern, eine PHP-Version
zu entwickeln. Nur sei dir halt dessen bewusst, wie unglaublich
fehleranfällig PHP-Quelltext ist, der von nicht ganz erfahrenen Leuten
geschrieben wird. Und denk daran, nicht zu viel Arbeitskraft zu
vergeuden. Schau dir OpenOffice und LibreOffice an, die haben ein
ähnliches Problem.
Ja, ich kann mir auch gut Vorstellen dass PHP eine "gewachsene" Struktur
ist in dem viel rein gemacht wurde weil es mal jemand gebraucht hat. Ich
hab auch schon ein Befehl gefunden, der tatsächlich nicht existiert
(ausführbar ist). Eine riesige Liste mit allen möglichen und unmöglichen
Funktionen und doch nicht das dabei wie ich wollt (Preisanzeige mit
dynamischen Kommastellen von 2..5 Stellen).
Ich möchte auch nicht zu viel in die Web-Oberfläche stecken, es reicht
wenn man per Web die Daten abrufen kann.
z.B. dass wenn man unterwegs beim Einkaufen ist, dann könnte man noch
schnell die Bestell-Liste überprüfen.
Eingaben incl. aller Sicherheitsabfragen sind dann nicht nötig. Auch
sollte es dann kein Sicherheitsproblem / unautorisierte Änderung der
Daten geben.
Anbei eine Erweiterung, Baumansicht der Typen für Filterung von
Bauteilen unter "Bauteile".
Klick auf Baum, dann Klick auf Bauteil-Bezeichnung, dann öffnen sich die
Details.
So, und jetzt seid ihr dran ;-)
Naja herzlichen Glückwunsch. Du hast prompt zwei der übelsten
Fehlerquellen eingebaut, die man einbauen kann ;-)
1
if(isset($_GET["TVID"]))
2
$TVID=$_GET["TVID"];
3
4
if(!isset($TVID))
5
$TVID=0;
6
7
buildTreeView($action,$TVID);
Du verlässt dich zum einen darauf, dass $TVID zwangsläufig über $_GET
herinkommt. Das geht schief für den Fall, dass register_globals
eingeschaltet ist. Die isset()-Funktion benötigt man, wenn überhaupt,
nur im Zusammenhang mit $_GET/_POST/_COOKIE, niemals aber bei einfachen
Variablen!
Und zum anderen winkst du das, was über TVID herinkommt, nahtlos
ungelesen an den Datenbankserver weiter. Das ist brandgefährlich, denn
ich kann ganz einfach beliebige SQL-Befehle an die Datenbank schicken
(SQL injection!).
Unter der Voraussetzung, dass sich der Baum selten ändert, würde ich
übrigens ein Nested Set deiner hierachichen Eltern-Kind-Beziehung
vorziehen. Dann ließe sich mit nur einer SQL-Abfrage der gesamte Baum
aus der Datenbank holen, ganz ohne rekursive Funktionen und solcherlei.
Du musst überdies unbedingt mal nach deinem HTML schauen, da fehlen
überall Anführungszeichen bei den Attributen.
Deine zweite Beschreibung deines Vorhabens (mal eben den Bauteilbestand
beim Einkauf prüfen) klingt schon deutlich besser.
Ja, dass denke ich mir, dass da einige Sicherheitsabfragen fehlen. Die "
in den Attributen, hab ich zum Teil vergessen rein zu nehmen.
Wie schon zu Anfang geschrieben, ich bin blutiger Anfänger in Sachen
PHP.
Hingegen in der EleLa EXE sind die ganzen Sicherheitsabfragen überall
drin, wenn doch was schief geht wird es richtig geloggt, incl
Funktionsaufrufhierarchie.
Ist schon ein enormer Nachteil, dass in PHP eine Variable immer der Typ
Variant ist und nicht spezifiziert wie bei C oder Pascal.
So würde es besser aussehen:
1
if (isset($_GET["TVID"]))
2
$TVID=$_GET["TVID"];
3
else $TVID=0;
>Deine zweite Beschreibung deines Vorhabens (mal eben den Bauteilbestand>beim Einkauf prüfen) klingt schon deutlich besser.
Es soll ja auch kein Totengrab werden, sondern ein Add-On zum
bestehenden EleLa.
Markus Müller schrieb:> Wie schon zu Anfang geschrieben, ich bin blutiger Anfänger in Sachen> PHP.
Das ist ja kein Verbrechen. Darum geb ich dir ja die Hinweise :-)
> So würde es besser aussehen:>
1
if (isset($_GET["TVID"]))
2
> $TVID=$_GET["TVID"];
3
> else $TVID=0;
Exakt. Noch besser sogar:
1
if(isset($_GET['TVID']))
2
$TVID=intval($_GET['TVID']);
3
else
4
$TVID=0;
Dann ist $TVID garantiert eine Zahl und schon ist diese Sicherheitslücke
behoben.
Denn: Die Baum-Ansicht wird von bauteil.php aufgerufen. Wenn man möchte
kann von da aus die $TVID schon vorbelegt werden. (Das war auch heute
Nacht mein ursprünglicher Gedanke)
Dann solltest du den ganzen Baum in eine Funktion verpacken. So wie
jetzt ist es jedenfalls Murks --
Tu doch mal so, als ob du das in Delphi programmieren müsstest. Dann
nämlich gäbe es auch kein isset() :-)
Der Code vom Baum kommt auch nicht von mir, das ist ein Demo aus dem
Netz. Siehe Copyright zu Beginn der Datei. Das Demo war für Frames
ausgelegt. Um mehr Performance zu erreichen müsste man das ganze auch
als Frames aus legen, dann würde der Baum auch nicht immer mit neu
aufgebaut werden.
>Tu doch mal so, als ob du das in Delphi programmieren müsstest. Dann>nämlich gäbe es auch kein isset() :-)
Das ist leichter gesagt als getan, ich kenne einfach zu wenige Befehle
in PHP, bzw. habe noch nie ein einfaches "ordentlichen" Projekt
gesehen/erklärt bekommen.
Wahrscheinlich ist es am besten man macht aus dem Baum eine Klasse, denn
der Baum könnte man auch für die Projektansicht gebrauchen.
Ich habe ein paar Kleinigkeiten geändert und auch die Datei typ.php
gelöscht. Denn die Baumansicht ist unter Bauteil drin und somit nicht
extra nötig.
Anbei wieder etwas mehr...
Bauteilansicht mit Baum, Baumansicht kann jetzt öfter verwendet werden,
ist zwar immer noch keine Klasse, dafür ist die gleiche Routine jetzt
auch unter Projekt drin (nur ein mal geschrieben in treeview.php).
Bei Klick auf das Bauteil sind nicht nur die Lager/Gehäuse Einträge
ersichtlich sondern auch das zugehörige Foto aus der Datenbank. (Siehe
Bild)
Projekt: Mit Baum als Filter. Klick auf das Projekt zeigt das Foto sowie
die Positionen.
Datei config.php enthält jetzt keine globale Funktionen mehr, die sind
jetzt alle in globalfunc.php. Damit muss man nicht mehr jedes mal die
MySQL Verbindungsparameter neu setzen.
Am besten die alten Dateien alle löschen und neu aus dem ZIP
einkopieren.
PS: Bisher finde ich die PHP Programmierung richtig cool. Der Notepad++
hat auch die ganzen Befehle in der Auswahlliste.
Der Download eines PDF Dokumentes hat noch nicht funktioniert, anbei die
geänderten Dateien. Jetzt klappt das auch von überall her.
globalfunc.php ersetzen
dl.php ist neu
adresse.php hatte noch ein Fehler drin
- PDF, GIF, PNG, JPG werden in einem neuen Fenster/Tab direkt geladen
und angezeigt.
- alle anderen Dateien werden als Download geladen.
- Geht auch über Internet, nicht nur im Intranet.
Aber Vorsicht: Wenn man im Projekt interne Dokumente, Schaltpläne als
Handbuch angehängt hat, dann können diese jetzt auch über Internet
"gestohlen" werden!!!
Um das zu verhindern müsste man z.B. in der Datei "dl.php" eine Regel
einbinden die verbietet, dass z.B. alle Dateien mit der Endung ".T3001"
(hier als Beispiel Target Datei) nicht geladen werden können, siehe
Array-Variable "$ExcludeExt" die beliebig erweitert werden kann.
Es müsste heißen: 'if ($Query === false)' (drei Gleichheitszeichen!).
Die Methode, mit der du Bilder in HTML einlagerst, funktioniert mit
nicht ganz aktuellen IE nicht. Vielleicht solltest du überlegen, ob die
Bilddaten überhaupt in die Datenbank gehörten -- der übliche Weg wäre,
in der Datenbank nur etwa IDs zu speichern.
In 'dl.php': stop execution macht man eigentlich nie. Regulär schon
garnicht mit die(), sondern dann mit exit(). die() ist für fatale Fehler
gedacht.
Und ebenda noch zwei gefährliche Lücken:
(1) Cross-Site-Scripting, denn du reichst $_GET['file'] ungesehen an den
Browser zurück. Man könnte beliebiges HTML da hineinbetten.
(2) Du prüfst $file nicht. Man kann sich jede beliebige Datei auf dem
Server herunterladen! (Leserechte vorausgesetzt)
Ich habs auch nochmal versucht mit PHP und meiner Datenbank und habe
aufgegeben. PHP ist so inkonsistent an allen Ecken und Enden und selbst
etablierte Datenbankschnittstellen sind einfach nur zum Kotzen
umgesetzt. Schade :-/
Vielen Dank für die Infos!
=== hab ich gemacht.
Mit dem IE muss ich anschauen. Die Bilder möchte ich in der DB halten,
denn wo soll ich die sonst haben. Extra hunderte Dateien irgendwo liegen
ist nicht praktisch. Zudem gibt es für EleLa auch die Import/Export
Funktion, die nutzt exakt die gleiche Datenbank. Also die Bilder sind in
der Datenbank, in einer extra Tabelle "foto".
Ja, stimmt, das wäre eine Fatale Sicherheitslücke!
Ich werde den Download auf Tabelle/ID ändern, dann kann man nur die
wirklich hinterlegte Datei laden.
Ja, PHP ist das eine, aber die vielen Browser dazu, die auch nicht
unbedingt das machen was die sollen :-/
Beispiel <table> <th>, der Firefox druckt auf jeder Seite den
Tabellentitel, der IE nicht. Daher ist der IE für mich nicht das Maß der
Dinge. Wenn man möchte dass es ordentlich geht muss man nun mal einen
Browser verwenden was die HTML Befehle richtig implementiert hat.
Was natürlich nicht heißt, dass ich es nie versuche dass es mit dem IE
auch richtig geht. (abgesehen davon hab ich nur den ollen original XP
IE.)
Ein paar Daten relativ simpel über PHP ohne Schnörkel und sonstwas an zu
zeigen, das sollte doch jetzt nicht das rießen Problem sein. Es sind
doch fast nur "Grundfunktionen" die ich nutze, kaum spezielle Extras.
Anbei die neue Version.
- Die Sicherheitslücke der Datei laden ist jetzt weg, es wird jetzt der
Tabellenname sowie die ID übermittelt, das Script dl.php sucht dann den
Name/Link heraus.
- config.php wurde mit ein paar Variabeln erweitert, so ist jetzt auch
die Array-Variable "$ExcludeExt" dort enthalten und nicht mehr in
dl.php.
- Bauteile Detailansicht jetzt auch mit Lieferant
- Überall Bilder hinzugefügt, sonstige kleine Verbesserungen.
Am besten alle Dateien löschen und die neuen aus dem ZIP neu einkopieren
und in der config.php die MySQL Verbindungsdaten wieder rein schreiben.
Puh, also ganz ehrlich? PHP ist zwar weit verbeitet und das nehme ich
auch bei kleinen Skripten, die in einem abgeschlossenen Netzwerk laufen
sollen. Aber für ein so umfangreiches Projekt würde ich das vergessen.
Wie Sven schon sagt, ist PHP zu einem Riesengebastel geworden. Und
dadurch, dass es so einfach ist, lauern überall Sicherheitslücken. Da
verlierst du irgendwann den Überblick.
Ich bin ja schon fast fertig, zumindest für meinen Teil.
Ich mache die Bestell-Liste noch etwas breiter (mehr Felder) und das
Suchen-Fenster, dann hat sich das Web-Interface für mich erst mal
erledigt.
Eingaben möchte ich nicht machen, dafür gibt es die EXE (Win + Linux).
Wenn jemand möchte, kann er gerne was in einer anderen Sprache mal
anfangen, ich wäre gespannt darauf (unterstützen wegen
Datenstruktur/Funktionen kann ich gerne).
Diese paar PHP Funktionen von mir können auch gut als "Spickzettel"
verwendet werden um das in der anderen Sprache um zu setzen.
PHP ist für mich naheliegend, da es viele gute Doku zu allem möglichen
gibt, z.B. SelfPHP und C ähnlich ist. Sonst hätte ich das ganze nicht
innerhalb dieser paar Tage so schnell hin bekommen.
Naja, so schlimm ist PHP nicht.
In der nächsten Version werden erst mal alle defekten und doppelten
Funktionen raus geschmissen, dann ist es auch erst mal wieder etwas
schlanker (natürlich daneben noch die Sicherheitsupdates)...
Übrigens empfehle ich dir bei Benutzereingaben (GET) immer Funktionen
wie addslashes() empfehlen (oder wenn für MySQL die passenden MySQL-PHP
Funktionen), sonst ist es mit hacken sehr leichtes Spiel ;-)
>sonst ist es mit hacken sehr leichtes Spiel
Ich kenne natürlich die ganzen Sicherheitslücken nicht.
Hast Du mir ein kleines Beispiel?
Derzeit übergebe ich nur ID's, außer beim Download und da muss auch der
Tabellen-Name ein erlaubter sein, sonst verweigert dl.php den Download.
Anbei die neue Version, folgende Änderung:
- Bauteil mit "Schnellsuchen" Eingabefeld, damit wird die Bauteilliste
verkleinert, Wildcardzeichen ist *.
- Die Status-Felder haben jetzt auch die richtige Hintergrundfarbe
- Die Links sind jetzt in der richtigen Schriftart
- Bestell-Liste hat jetzt auch das Status-Feld.
Anbei alle Dateien im Zip, die entpacken und ersetzen.
Anbei die neue Version, folgende Änderung:
- Jetzt passt auch das CSS Style-Sheet
- kleinere Zwischenräume in den Tabellen, damit passt mehr auf den
Bildschirm
- Bilder werden jetzt auch mit dem M$ IE gezeigt
- Bauteil > Lager/Gehäuse mit Link auf Gehäuse
- Bauteil > Lieferant Link mit Bestellnummer direkt zum Lieferant
- Info-Seite mit Copyright und Lizenzbestimmung
Anbei alle Dateien im Zip, die entpacken und ersetzen.
Was wohl gemeint war mit hacken ist:
dann könnte ein "hacker" einfach die variable manipulieren, heißt: Get
wird ja per URL übertragen, also: xyz.de/index.php?VARIABLE=INHALT
Wenn man jetzt böse ist und einfach manipuliert sowas macht:
xyz.de/index.php?VARIABLE="BÖSER CODE"
Daher kann so was passieren:
PHP:
echo "Die Variable heißt: " . $_GET['Variable']; //Variable ausgeben
gewollt ist in HTML dadurch Bsp.:
Die Variabel heißt: xyz
aber durch Manipulation mit HTML Zeichen wie < lassen sich dann andere
Dinge einbauen, als Beispiel ganz einfach:
xyz.de/index.php?VARIABLE=<img src=...>
dann würde ein Bild ausgegeben was nicht gewünscht war etc.
Dagegen hilft die Funktion: htmlentities ->
http://php.net/manual/en/function.htmlentities.php
Weiter gibt es die Möglichkeit durch "" Zeichen den PHP Code zu
manipulieren (PHP injection) dazu siehe:
http://www.flashforum.de/forum/php-und-mysql/tutorial-php-code-injection-197417.html
Vielen Dank für die Erklärung, ich denke ich habe das jetzt verstanden.
Ich meine ich habe keine Sicherheitslücke mehr drin.
- In der Regel werden nur ID-Zahlen übergeben, die werden alle mit
is_numeric() / intval() geprüft / gewandelt
- Bei der Anzeige des Handbuchs wird der Tabellen-Name übergeben und der
muss exakt einem Name aus der erlaubten Liste übereinstimmen.
Somit sollte es keine Sicherheitslücke in der aktuellen PHP Version
geben.
Hier aus dl.php:
Ich habe die Suchen-Felder einmal überprüft.
- ' < > klappt
- " klappt nicht
Also habe ich jetzt alle " Zeichen aus dem Suchtext entfernt. Wenn ich
das nach \" wandle klappt das auch nicht.
Ein anderen Code konnte ich damit nicht ausführen.
Nur das eine " Zeichen bereitet Probleme bei der wiederanzeige des
Suchtextes in der Eingabebox deshalb habe ich es entfernt und es sollte
somit auch hier keine mögliche Sicherheitslücke mehr da sein.
Ich hab das mal getestet mit "addslashes", geht leider nicht richtig.
Meine Methode in der ich einfach die " entferne funktioniert viel
besser, denn dann werden zumindest die ' erlaubt.
Im neuen EleLa Setup wird das aktuelle EleLaPHP.ZIP auch mit in das
EleLa Verzeichnis kopiert, dann hat das jeder schon und kann das in sein
PHP einbinden.
Derzeit ist das Setup nur zum Test hier zu finden:
http://mmvisual.de/Setup_EleLa_Test.zip
Wenn niemand mehr einen Fehler finden, dann wird es das richtige Setup
sein.
Hallo,
beim Rumspielen mit der PHP-Version fiel mir auf, dass noch
SQL-Injection möglich ist.
Zum Beispiel erhalte ich mit diesem Suchbegriff alle Datensätze, weil
das OR TRUE in die WHERE-Klausel gelangt:
mysearchstring\' OR TRUE -- ab hier ist alles SQL kommentar
Da es (glücklicherweise) mit mysql_query nicht möglich ist, mehrere
verkettete SQL-Anfragen gleichzeitig abzusenden, konnte ich auf die
Schnelle keine Daten oder Tabellen löschen. Die potentielle
Sicherheitslücke bleibt aber. Ich selbst hab keine Ahnung von PHP, aber
es gibt eine Funktion mysql_real_escape_string, die Du Dir mal ansehen
solltest. Am Lohnendsten sollte es aber sein, sich mit sog. prepared
statements vertraut zu machen.
Ich hoffe, mein Kommentar nützt Dir etwas.
Andreas
Vielen Dank!
Ich schaue mir das mal an. Ich habe schon gesehen, dass PHP extrem
Sicherheitskritisch ist, daher soll EleLaPHP auch eine "nur Viewer"
Version bleiben.
Ich habe Bauteil und Suche abgeändert. Jetzt wird die Eingabe \' nicht
mehr zugelassen.
Mit EleLa >> Extras >> Info >> Versionsabfrage kann EleLaPHP V1.2.11B28
geladen werden.
Markus Müller schrieb:> Ich habe Bauteil und Suche abgeändert. Jetzt wird die Eingabe \' nicht> mehr zugelassen.
Das löst das Problem ansich (SQL-Injections) aber nicht.
Deutlich besser ist es, die Variablen direkt vom SQL-Server einfügen zu
lassen, "Prepared Statements" als Stichwort.
1
$stmt=$conn->prepare("SELECT * FROM table WHERE column = ?");
2
if($stmt->execute(array("foobar"))===false){
3
die("error");
4
}
Um das Statement deutlich übersichtlicher zu machen kann man das
Statement in eine externe (.sql-)Datei auslagern und soetwas wie folgt
machen:
1
SET@placeholder=?;
2
SELECT*FROMtableWHEREcolumn=?ORcolumn2LIKE?
Dadurch erspart man sich auch das 5-malige escapen (bei den prepared
Statements übrigens überhaupt nicht erforderlich!) und verwursten der
Variablen. Zudem ist es deutlich übersichtlicher ;)
HTH
Chris
Hi Markus,
ich muss Chris zustimmen. Ich wollte Dich eigentlich auch Richtung
Prepared Statements schubsen :)
Durch das Ersetzen von \' sind nur minimale Änderungen im Suchstring
nötig, um das gleiche Ergebnis zu erzielen:
mysearchstring\\'' OR TRUE -- ab hier ist alles SQL kommentar
Wenn Dir die Einführung von PreparedStatements für den Anfang zu
aufwändig ist, habe ich folgende Empfehlung (am Beispiel von suche.php)
Am Anfang der Datei musst Du mit dem Suchstring gar nichts machen, wenn
er nicht leer ist:
1
if (isset($_GET["ss"])) // Suche Texteingabe
2
{
3
$ss = $_GET["ss"];
4
if ($ss == '') $ss = '*';
5
} else $ss = "*";
Weiter unten machst Du die Eingabe, so wie der Nutzer sie eingegeben
hat, sicher, indem Du die Funktion mysql_real_escape_string() benutzt:
1
if (isset($_GET["ss"])) // Suche
2
{
3
$ss = str_replace('*', '%', $ss);
4
$ss = mysql_real_escape_string($ss);
5
if (strpos($ss, '%') === false)
6
$ss = $ss."%";
7
...
Ich habe eine Reihe von Tests durchgeführt und es scheint zu
funktionieren. Alle kritischen Zeichen werden "escaped" (wie sagt man
das auf Deutsch?) und die Suchen, die ich durchgeführt habe, liefern das
erwartete Ergebnis.
Aber danach wurde ich mutig. Ich habe testweise ein Bauteil mit dem
ominösen Namen
mysearchstring\' OR TRUE -- ab hier kommentar
anlegen wollen, aber da meckerte Elela, dass ein Bauteil dieses Namens
schon existierte. Das zeigt, dass SQL-Injection auch im Hauptprogramm
möglich ist. Was geklappt hat war ein Bauteil mit dem Namen
mysearchstring\' OR FALSE -- ab hier kommentar
anzulegen, und zwar 2x. Danach wurde ein doppelter Eintrag in der
Datenbank erkannt und ich konnte erst weiterarbeiten, als ich den
zweiten Eintrag gelöscht hatte.
Mit diesem komischen Bauteil in der Datenbank hab ich nochmal die
PHP-Suche ausprobiert. Folgendes hatte Erfolg:
mysearchstring*
mysearchstring*'*
mysearchstring*' OR FALSE -- ab hier kommentar
*'*
Sobald ich aber den Backslash mit eingegeben habe, wurde kein Ergebnis
mehr geliefert. Mit 2 Backslashes ging es:
mysearchstring\\' OR FALSE -- ab hier kommentar
Das hängt vermutlich davon ab, wie die Daten genau in der Datenbank
stehen. In der Praxis spielt das sicher kaum eine Rolle, aber wenn Du
eine saubere Lösung haben willst, solltest Du die Eingaben in Elela noch
für die Datenbank aufbereiten. Dafür gibt es sicher auch fertige
Funktionen in C (oder welche Sprache Du auch verwendest). Anschließend
sind auch die komischen Eingaben wie "mysearchstring\' OR TRUE -- ab
hier kommentar" kein Problem mehr. Oder Du nutzt, um mal einen Bogen zum
Anfang des Posts zu schlagen, Prepared Statements. Damit hältst Du Dir
jetzt und in Zukunft alle derartigen Probleme vom Hals. Sie sind das
Mittel der Wahl bei allen Datenbankoperationen aus einer
Programmiersprache heraus.
Ich hoffe sehr, dass Du meinen langen Post nicht als Abwertung Deiner
Arbeit verstehst. Im Gegenteil, ich hoffe, Du machst noch lange weiter
und ziehst Nutzen aus einem kritischen Blick von außen :)
Andreas
Hallo Andreas,
Vielen Dank für die Tests und Infos.
Vor allem dem "mysql_real_escape_string()", diese Funktion muss ich als
"MyRealEscapeString()" in die globalfunc.php rein nehmen, damit ist das
ganze für andere Datenbanken vorbereitet.
Ich habe mit das mit den "Prepared Statements" von Chris schon
angeschaut, aber ich wusste nicht wie ich das richtig/einfach in
EleLaPHP umsetzen kann.
Wegen der EXE, kannst Du mir ein paar Screenshots mailen, wie das ganze
aussieht?
Vielleicht können wir auch mal eine Online-Sitzung machen, dann kann ich
mir das "Live" anschauen.
Denn wenn ich das in EleLa umbaue, dann ist das doch ein etwas größerer
Aufwand, mindestens 200 SQL Scripte sind da verbaut.
Wobei man ohnehin nahezu Vollzugriff auf die Datenbank mittels Extras >>
Datenbank hat. Daher ist der SQL-Inject in der EXE nicht ganz so
dramatisch. (Ist von mir auch so gewollt damit jeder selbst
Spezialabfragen / Exports machen kann)
Grüße Markus
Was die Übernahme von Daten per GET/POST angeht, kann man auch settype
nutzen. Hilft auch gleichzeitig, nicht übergebene Variablen zu
erstellen.
Auch sowas wie
1
if (isset($_GET["ss"])) // Suche Texteingabe
2
{
3
$ss = $_GET["ss"];
4
if ($ss == '') $ss = '*';
5
} else $ss = "*";
lässt sich eleganter schreiben, zumal isset() nicht in allen Fällen
wirklich sinnvoll ist. Bei Strings empfehle ich strlen() bzw.
mb_strlen().
1
if (strlen(GET["ss"])>0) {
2
$ss = $_GET["ss"];
3
} else {
4
$ss = "*";
5
}
Kürzer, aber unleserlich wäre:
1
$ss = ((strlen(GET["ss"])>0)?$_GET["ss"]:"*");
Grüße
Udo
PS: Ich stelle auch gerne Teile meines PHP-Frameworks (z.B.
Datenbankklasse oder ähnliches) zur Verfügung. In einer späteren Version
wäre vielleicht Ajax ganz sinnvoll. Hab mit dem Dojo-Framework in der
Beziehung gute Erfahrungen gemacht.
Markus Müller schrieb:> Ich habe mit das mit den "Prepared Statements" von Chris schon> angeschaut, aber ich wusste nicht wie ich das richtig/einfach in> EleLaPHP umsetzen kann.
janz enfach ;)
ich hab dir zwei Dateien aus meiner "persönlichen" Bibliothek angehängt.
Daher weder Garantie auf Korrektheit und Vollständigkeit.
Das "nette" an meinem Konstrukt ist, dass du (in Verbindung mit PDO) nur
die *_mysql.php kopieren musst und die Datenbankeigenen
Connectionstrings einfügen musst. Von PDO werden schon einige
Eigenheiten der verschiedenen Datenbanken abgefangen, den rest kann man
auch über Funktionen wie z.B. $db->GetDateConst(); (aktuell nicht
implementiert) bekommen. (Für jede DB muss man diese Konstanten halt
einzeln pflegen)
Oder eben die Statements in verschiedene externe Dateien auslagern und
von dort laden. Das kann man je nach Datenbanktyp auch automatisch
machen.
Zum Beispiel kann man (bei Implementierung in den Klassen) folgendes
machen:
Die Queries in Dateien sind in strukturierter Form wie
bestellung.sqlite.sql; bestellung.sql
Beim Laden des Statements wird zuerst geprüft, ob es für den jeweiligen
Datenbankadapter ein spezifisches File gibt, wenn nicht wird geprüft ob
es ein allgemeines File gibt (geimeinsamer Syntax im SQL). Wenns nix
passendes gibt kann man immernoch crashen ;)
Hier noch ein kleines Beispiel für die Benutzung meiner Lib:
print_r($db->FetchAllRowsAssoc(file_get_contents("suche.mysql.sql"),$_GET["ss"]);//ja, das darf man hier wirklich!
Die EleLa ist so wie ich es gesehen hab' ausschließlich prozedual
geschrieben. Ich weiß, wenn man objektorientierte Programmierung nicht
kennt, sieht sie wie ein Monster aus. Aber durch sie kann man sich das
Leben deutlich leichter (und den Code übersichtlicher) machen.
Hi Markus,
Markus Müller schrieb:> Wegen der EXE, kannst Du mir ein paar Screenshots mailen, wie das ganze> aussieht?> Vielleicht können wir auch mal eine Online-Sitzung machen, dann kann ich> mir das "Live" anschauen.
ich hab grad keinen Zugriff auf den Elela-Rechner. Ich bereite am
Freitag mal ein paar Screenshots zum Nachverfolgen vor.
Hi Markus,
hier sind ein paar Screenshots.
1) Wenn ein Bauteil angelegt wird, das ein \' im Namen hat, wird ein
SQL-Syntaxfehler gemeldet.
2) Wenn man den Bauteilnamen mit einem SQL-Kommentar enden lässt, ist
die Syntax der SQL-Statements wieder korrekt (typisches
SQL-Injection-Szenario: http://xkcd.com/327/ :))
3) Einfügen von OR TRUE in eine SQL-WHERE-Klausel. Die interne Abfrage,
ob ein Datensatz mit diesem Namen schon existiert gibt damit
fälschlicherweise true zurück.
4) Mit Klick auf OK springt man zum ersten Datensatz, weil ein Bauteil
dieses Namens doch noch nicht existiert.
Die Datenbank im Hintergrund ist bei mir übrigens MySQL.
Ich hoffe, das hilft Dir weiter.
Andreas
Vielen Dank für die Screenshots!
Ich muss da mal forschen woran das liegt. Die Komponenten sind
automatisch mit der Query verbunden und ich habe so keinen Einfluss in
meinem Code.
Ich werde da mal im Lazarus-Forum nachfragen.
Vielleicht wäre es gut ein so großes Softwareprojekt mit Hilfe einer
Versionsverwaltung oder einem Contenttracker zu verwalten.
z.B. github.com kann für freie Software kostenlos folgende Dienste zur
Verfügung stellen:
* Versionsverwaltung mit git,
* ein Wiki,
* ein Issuetracker,
* forken/mergen (insgesamt der gesamte kollaborative Part) ist sehr gut
auf github.com
Hi Markus,
ich hab den Thread im Lazarus-Forum verfolgt und denke auch, dass Du auf
dem richtigen Weg bist. Bevor Du jede einzelne Query in Elela
bearbeitest, kannst Du Dich ja erstmal auf eine Maske (z.B. Bauteile)
konzentrieren und dann eine Testversion zur Verfügung stellen.
Ansonsten lass mich zum Trost sagen, dass Du nicht der einzige bist, der
sich gerade durch so eine Aufgabe quält :)
Andreas
Ich kenne diverse Programme wie SVN oder CVS. Ich nutze die nicht, da
ich alleine programmiere und mich eher "belasten" als erleichtern.
Ich mache öfter ZIP-Archive, da ist dann alles drin und in sich
konsistent.
Mein ganzes EleLa Verzeichnis, samt Sicherungen hat schon über 1GB auf
der Platte belegt. Sicherung auf 4 Festplatten (davon 2 USB-Platten),
daher geht garantiert nichts verloren. Programmierumgebung auf 2
Rechnern.
Man könnte mit solch einer Versionsverwaltung zwar auch einen alten
Stand raus holen, aber mal ehrlich, wer braucht das?
Wenn ein Bug drin ist, dann muss der im aktuellen Release raus.
Meist kommen Bugs rein, indem ich eine neue Funktion hinzu programmiere
und in meinen Tests nicht finde, bzw. Folgeerscheinungen in Zusammenhang
von anderen Funktionen und da hilft auch kein alter Stand.
Die Dokumentation der Versionen zu EleLa macht auch EleLa selbst mit
Hilfe eines Projektes und der Historie. Ich lasse immer wieder eine
"UpdateBeschreibung.pdf" raus und stelle diese ins Forum.
@Andreas
Dann teste mal...
EleLa >> Extras >> Info >> Versionsabfrage
V1.2.11C02
Nur die eine Abfrage, wie in Deinen Bildern gezeigt habe ich geändert
und sollte jetzt richtig gehen.
Nun sollte EleLaPHP sicherer sein. Ich habe unter glopalfunc.php diese
Funktion hinzugefügt:
1
// String zu Datenbankabfrage sicher wandeln
2
functionMyEscapeString($Text)
3
{
4
global$P_DBTyp;
5
$Result="";
6
if($P_DBTyp=="MySQL")
7
{
8
$Result=mysql_real_escape_string($Text);
9
}elseif($P_DBTyp=="PostgeSQL")
10
{
11
$Result=pg_escape_string($Text);// <<< muss noch geprüft werden!
12
}elsedie("Datenbanktyp $P_DBTyp wird nicht unterstützt (MyEscapeString)");
13
return$Result;
14
};
Die wird von bauteil.php und suche.php verwendet.
EleLaPHP V1.2.11C03 kann mit EleLa >> Versionsabfrage oder direkt von
meiner Homepage geladen werden.
Hi Markus,
die gute Nachricht zuerst: ich hab es nicht geschafft, einen SQL Fehler
zu provozieren, weder bei der Eingabe in Elela, noch bei der Suche in
der PHP-Anwendung.
Leider sind mir noch 2 andere Probleme aufgefallen.
1) Backslashes in der Suchanfrage werden automatisch escaped, das heißt,
wenn der zu suchende Datensatz einen Backslash enthält (z.B. ein Bauteil
namens somestring\ ),
muss die Suchanfrage mit 2 Backslashes formuliert werden: somestring\\
Das gilt sowohl für die Exe als auch für die PHP-Version. Ein Workaround
in der PHP-Version könnte sein, alle Backslashes in der Suchanfrage zu
verdoppeln:
1
$ss = str_replace('%', '%%', $ss);
2
$ss = str_replace('*', '%', $ss);
3
$ss = str_replace('\\', '\\\\', $ss); //aus eins mach zwei
4
$ss = MyEscapeString($ss);
5
if (strpos($ss, '%') === false)
6
$ss = $ss."%";
Da anschließend die Eingabe mit MyEscapeString gereinigt wird, tut sich
m.E. damit auch keine Sicherheitslücke auf.
Ich habe bislang nur mit MySQL getestet und kann nicht sagen, ob das
Backslashproblem auch bei anderen Datenbanken auftritt. Wenn das
Verhalten unterschiedlich ist, müsste die Backslashverdopplung evtl.
nach MyEscapeString ausgelagert werden. Vielleicht gibt es auch eine
Datenbankeinstellung, die die Verdopplung der Backslashes überflüssig
macht.
2) Die Eingabe von Anführungszeichen (") in der Suche der PHP-Version
sorgt dafür, dass sich eigener HTML-Code einfügen lässt.
Der Grund ist die Zeile
Damit kann durch die ungeprüfte Übernahme von Zeichen kaputtes HTML
erzeugt werden, was das Einbetten von eigenem HTML und Scripten
ermöglicht. Führe mal eine Suche mit folgendem String aus und klicke
dann nochmal ins Eingabefeld:
Ich habe jetzt nicht den ganzen thread durchgelesen aber weiter oben
hast du nach einer Alternative zu PHP gefragt ->
Für diesen Anwendungsfall ist Ruby on Rails praktisch perfekt geeignet.
Unter anderem weil du per Auswahl des Datenbankadapters nicht so ein
Gepfusche machen musst und du selber kein SQL mehr schreiben musst.
Weiterhin wird automatisch korrekt escaped und Schutz gegen CSRF in
Formularen ist schon eingebaut. Du kümmerst dich nur noch um deine
Applikationslogik und Views und den Rest besorgt Rails für dich
automatisch
Wenn du bei PHP bleiben willst, dann schau dir mal Smarty als
Templatesystem an. Dieses echo "html-code" ist ja wohl das gruseligste
überhaupt und seit der Steinzeit schon nicht mehr aktuell.
http://guides.rubyonrails.org/getting_started.htmlhttp://ruby.railstutorial.org/ruby-on-rails-tutorial-book
@Andreas
Vielen Dank für die Tests!
Ich habe htmlentities() hinzu gefügt, jetzt sollte auch der HTML-Inject
weg sein. (Unter Suche und in Bauteil)
Das "//aus eins mach zwei" hab ich auch hinzu gefügt.
Wenn ich jetzt ein Bauteil mit dem Name "\" anlege und im Suchen nur ein
"\" eingebe, dann klappt das Finden nicht, erst wenn ich ein "\*"
eingebe.
Aber daran würde ich jetzt nicht zu sehr Wert legen und unter "Known
Bugs" ablegen.
In meiner EXE-Version (die gleiche wie in der Versionsabfrage) kann ich
in Suchen ein " eingeben und es kommen keine Ergebnisse.
EleLaPHP V1.2.11C05 kann mit der Versionsabfrage geladen werden.
@ D.I.
Ja, Ruby wurde schon mal genannt, ich habe mir das einmal ein wenig an
geschaut, aber kam damit nicht zurecht.
Zu tief wollte ich mich damit nicht beschäftigen, denn EleLaPHP soll die
ganze EleLa Eingabe auch nicht ersetzen sondern nur ein Viewer werden.
Der zweite Grund warum ich PHP verwendet habe ist, dass PHP viele Leute
beherrschen und das bereits mit XAMPP das PHP gleich mit installiert
wird.
Ja, stimmt. PostgreSQL wird derzeit nicht ganz unterstützt, da fehlen
noch ein paar Codezeilen in der globalfunc.php.
Bisher hatte auch noch niemand den Wunsch das mit PostgreSQL zu
machen ;-)
Ich habs bei mir geändert.
Hi Markus,
das ist seltsam. Bei mir funktioniert die Suche ohne Stern, sowohl mit
einem Bauteil namens \ als auch einem Bauteil namens "\"
Die Debug-Ausgabe ist übrigens noch an.
Andreas
Doch jetzt geht das bei mir auch, außer "*\", da wird das \ Bauteil
nicht gezeigt.
Ich habe V1.2.11C05b hochgeladen, jetzt ist auch die Debug-Ausgabe
wieder weg (auskommentiert).
Und das "r" von Frank ist auch drin.
Hallo Zusammen,
bis vor zwei Tagen lief mein EleLa einwandfrei, dann habe ich am Server
eine Update (apt-get update / apt-get upgrade) durchgeführt. Jetzt kann
der Client nicht mehr auf die Datenbank zugreifen. Mit phpmyadmin komme
ich noch ganz normal auf den Server und sehe die Datenbanken.
Woran kann das liegen?
Hier die Fehlermeldung:
22:12:41 Error: Cannot open database! Access violation (DB-Connect)
Gruss Toni
Hallo,
ich spiele gerade mit deinem Elela und habe mir dazu die Elela_PHP auf
meinem Server installiert. Frage: kann man in der PHP-Version keine
Bauteile/Projekte hinzufügen? Geht das nur im Programm? Oder habe ich da
eine Funktion nicht aktiviert?
Grüße (und weiter so ;-) )
Mit EleLaPHP kann man nur Anzeigen. Damit kann man von unterwegs mal in
die Datenbank schauen, das war das Ziel.
Vielleicht klappt es ja mal dass sich die Datenbanken von PartDB und
EleLa angleichen, dann könnte man dieses Tool als Web-Frontend nutzen.
Ich selbst habe leider zu wenig Erfahrung & Zeit das richtig zu machenl.
Hallo Zusammen,
der Thread ist ja schon ein wenig betagt. Trotzdem die Frage, ob das
Projekt EleLa in der PHP-Version noch aktiv ist und falls ja, ob es eine
Anpassung auf die PHP version 7+ geben wird oder bereits gibt?
Nebenbei, großen Respekt für die Entwicklung der Desktopversion ;-)
Ja, EleLa PHP ist schon etwas ähm "eingerostet". ;-)
Für die Zukunft ist schon ein besseres Web Frotend angedacht, das ist
jedoch noch nicht wirklich Spruchreif und wird sicher noch länger
dauern.
Da ich auch mehr an einer PHP Verion interessiert wäre, würde ich mich
sehr freuen wenn es hier weiter gehen würde.
Also am besten wird nur noch PHP gemacht und die andere Version
eingestellt.
Aber das ist wohl nicht zu erwarten.
Würde da auch gerne helfen, nur PHP kann ich leider nicht.
Wer eine gute Webbasierte Lagerverwaltung haben möchte sollte bei PartDB
mal vorbei schauen. Jan kann sehr gut Web Entwicklung machen und wie man
sieht ist das ebenfalls enorm viel Arbeit:
Beitrag "Lagerverwaltung Part-DB V0.5.x"
Ich konzentriere mich hingegen auf ein gutes PC Basierte Programm, da
ich von Web Entwicklung nicht wirklich viel Ahnung habe und auf 2
Hochzeiten ist immer schlecht zu tanzen.
Part-DB kenne ich und habe ich auch getestet.
Ist soweit auch nicht schlecht, aber EleLa finde ich einfach besser.
Ein mix aus beiden und Ihr könntet eigentlich jeden damit zufrieden
stellen.
Das mit 2 Hochzeiten kenne ich nur zugut und darum kann ich leider auch
nicht helfen. PHP ist halt weder C noch Pascal, auch wenn die Sprache am
Ende nur lernarbeit ist und recht wenig mit "Programmieren" zutun hat.
Aktuell sind die beiden Datenbanken im Hintergrund noch zu sehr
verschieden. Daher kann man diese beide "Front Ends" nicht mit der
gleichen Datenbank betreiben.
EleLa_PHP.png
(8,7 KB)
