Ik probeer een installer te maken voor mijn DB connectie.
- SQL bestand inladen (staat op de server) en vervolgens CREATE TABLE splitten d.m.v. ";" in een array en deze vervolgens te runnen als query. ik maar hiervoor een connectie via de invoervelden host, user, pass, db_name.
- Ik probeer deze zelfde vier textfiels te gebruiken om in een bestand db_connectie.php een mysql_connect(); en mysql_select_db(); permanente verbinden te leggen. dit bestand wordt vervolgens geinclude op alle pagina's.
het idee was om met file_put_content(); php te scrhijven in een php bestand (als dit al kan ?). Het bestand db_connectie.php is blanco geupload naar de server.
Het moeilijke is dat er dus <?php en ?> tags in een php bestand weggeschreven dienen te worden. Ik heb een lid genaamd jexus hier ooit de functie eval(); zien gebruiken om PHP in PHP te gebruiken.
Wellicht iemand een idee of een alternatieve wijze om d.m.v. textfields een permanente verbinding te leggen.
Thomas - 30/03/2016 14:53 (laatste wijziging 30/03/2016 14:57)
Moderator
Ai.
Wat probeer je met deze functionaliteit te doen?
* regelmatig database beheer
Gebruik hiervoor een pakket zoals phpMyAdmin, of werk vanaf de prompt
* installatieroutine van een stuk functionaliteit/systeem, of losse scripts voor kleine updates (patches)
Dit zou dan onderdeel uit moeten maken van het systeem; het systeem zou vervolgens precies moeten dicteren wat er gebeurt, de SQL-code zou dan al ingevuld moeten zijn. Als je vrijuit SQL wilt uitvoeren, gebruik dan phpMyAdmin
Mogelijk leg ik hier niet precies de vinger op de zere plek, maar de algemene indruk van wat je hierboven beschrijft (het genereren van allerlei code en het gebruik van eval()) gebiedt mij jou (instinctief?) aan te raden weg te sturen van deze oplossingsrichting.
EDIT: er ontbreekt ook een character encodering bij de selectie van je database. En daarnaast zijn de mysql_-functies al meer dan 10 jaar verouderd en binnenkort definitief verdwenen (in PHP 7 bestaat de standaard MySQL extensie (en daarmee alle mysql_-functies) niet meer). Op dit punt raad ik je met klem aan over te stappen op MySQLi of PDO. En daarbij expliciet een character encoding op te geven.
Het is een systeem wat gedupliceerd moet worden, uploaden, en database aanmaken.
Je kan het bijna zien als een firmwire, wellicht een enkele keer een update ivm met beveiligingsfouten.
Het gaat erom dat het systeem zo makkelijk mogelijk zonder enige kennis geïnstalleerd kan worden.
Deze optie leek mij wel aardig, ik wist al wel dat eval() een risico is maar ik heb niet echt andere voorbeelden waar ik van kan leren.
Dit is niet de bedoeling om PHPMyAdmin te omzeilen, het is een eenmalige handeling om de DB te createn en vervolgens kan men vanuit dit standaard CMS de DB invoeren / wijzigen / verwijderen op basis van formulieren die gekoppeld zijn aan de databank.
Wellicht heb je een suggestie hoe ik vanuit deze optiek een stabiele DB connectie op een veilige manier kan maken ?
Naar mijn mening zou je een eindgebruiker hier nooit mee moeten confronteren.
Daarnaast ligt datgene wat gecreëerd dient te worden (tabellen + mogelijke initiële gegevens) al vast door de functionaliteit. Dit is niet "variabel" en moet dus ook niet als invoerveld worden aangeboden. Dit alles kan achter de schermen gebeuren. Je wilt toch niet dat eindgebruikers hier zelf in of mee gaan rommelen?
Hetzelfde geldt voor updates: de wijzigingen die uitgevoerd dienen te worden liggen al vast, dit is geen punt voor discussie. En dus ook niet afhankelijk van user input.
Ook wil je, dat als je straks 15 van dit soort systemen hebt met versie X, dat deze toch alle dezelfde database-structuur hebben? Dan moet je op deze manier ook geen openingen daartoe geven.
Je moet het opzetten van een database-connectie, zoals bij bovenstaande installer gebeurt, zien als een aparte stap in het installatieproces. Nog voordat de installatie begint moet je op een of andere manier al een database + user hebben; meestal wordt deze informatie aangeleverd. De installatieprocedure controleert dan in een eerste stap of de opgegeven database-gegevens resulteren in een succesvolle connectie.
Van daaruit vervolgt het installatieproces zich en regelt de code onder de motorkap verder het aanmaken van tabellen, hier komt geen gebruiker aan te pas. Kijk maar eens hoe de installers van Joomla, Drupal, Magento en noem het maar op werken. Hier wordt in stap 1 wat algemene database-informatie gevraagd (host, username, password, databasenaam) en de rest regelt de installer automatisch, hier komt geen enkele gebruiker interactie meer aan te pas, behalve wellicht het opgeven van een wachtwoord/e-mailadres voor het standaard admin-account.
Long story short: eindgebruikers hebben NIETS te zoeken in de databaseSTRUCTUUR en hebben doorgaans beperkte privileges over de databaseDATA die door gebruikersrechten en interfaces worden afgedwongen/afgeschermd.
Afhankelijk van de schrijfrechten zou er dan een config.php bestand moeten worden gemaakt (of aangepast).
Overigens eens met Thomas m.b.t. het opzetten van de structuur, aanmaken van de tabellen: dat is inderdaad niet iets waar de gebruiker aan zou moeten kunnen/willen sleutelen.
Jointjeff; zo heb ik het ook gedaan inderdaad. Ik kwam zojuist een soortgelijk script tegen en het lijkt te werken.
Thomas, daar heb je gelijk in. De textarea geeft wellicht het idee dat men hier iets mee moet / kan doen en oogt verwarrend.
Ik heb het vooral toegevoegd omdat ik wilde zien of de externe pagina waar het SQL in staat wordt opgehaald en uitgelezen. Het bestand is echter ook leiden, je kan de textarea wel aanpassen maar heeft geen effect op het aanmaken van de database.
"Nog voordat de installatie begint moet je op een of andere manier al een database + user hebben"
dit is dus het probleem.
Thomas - 30/03/2016 15:47 (laatste wijziging 30/03/2016 15:51)
Moderator
@JointJeff Precies.
Het enige wat mogelijk gegenereerd zou mogen worden tijdens de installatie is een of ander configuratie-bestand voor de database-gegevens. De rest van de configuratie zou je eventueel kwijt kunnen in de database zelf.
Dan zou nog steeds grote zorg moeten worden besteed bij het samenstellen van het database-configuratiebestand. Indien je dit niet doet is het mogelijk om hier PHP-code in te injecteren. Waarmee je mogelijk backdoors of andere ongein mee uit kunt halen.
Je zou ook kunnen overwegen om deze informatie onder te brengen in een .ini-file met bijbehorende syntax, deze kun je vervolgens in 1x uitlezen met een parse_ini_file() opdracht. Deze is dan niet vatbaar voor mogelijke injectie van PHP-code.
@advertentiep
Dit is een preconditie voor de installatie, het is een vereiste. Je moet het niet aan de installatie zelf over laten om een database aan te maken maar deze moet binnen de kaders van een database opereren met een, bij voorkeur APARTE, speciaal voor deze applicatie gecreëerde, gebruiker. Stel dat er een lek zit in je applicatie, dan wil je toch niet dat dit systeem root-privileges in je COMPLETE databasesysteem heeft?
Misschien wel niet de beste manier, even snel gedaan. I.i.g. is er geen enkele vorm van validatie/filtering etc. toegepast dus uiterst onveilig om zo te gebruiken.
Daarnaast valt er ook wat aan te merken over de wijze van de db-queries, maar dit is even als voorbeeld.
Thomas - 30/03/2016 17:39 (laatste wijziging 30/03/2016 22:02)
Moderator
Het configuratiebestand zou m.i. enkel de gegevens moeten bevatten om een connectie te maken, maar dit niet zelf direct doen. Hoe je deze connectie maakt is aan de applicatie zelf. Mogelijk wil je op den duur een andere constructie gebruiken (PDO i.p.v. MySQLi) of een aparte (tweede) connectie maken. Met deze opzet gaat dat niet. Het maken van een connectie (en met welke gegevens dit gebeurt) zit hardcoded in het bestand :/.
Wederom ontbreekt in deze opzet een indicatie van de gebruikte character encoding. Die overigens ook in de CREATE TABLE definities ontbreekt, evenals de te gebruiken engine...
EDIT: En indien je formulieren weergeeft, doe dit dan in VOLLEDIGE en KLOPPENDE HTML documenten.
Kon je niet nog even een betaalmodule en een CMS scripten ? hehe..
Ziet er echt heel netjes uit maar ik zal gewoon eerlijk zijn. Ik kan niet op jouw niveau scripten. Gebrek aan ervaring en niet echt de interesse om OOP te leren. Het verschil zit niet alleen in de juiste karakters typen maar ook allround ervaring. De alternatieve oplossingen zijn bij mij heel erg primitief, omslachtig en ver gezocht.
EDIT; wellicht een idee voor mij om meerdere SQL bestanden te genereren afhankelijk van het type database en tabel.
uhh ja HTML forms, deze worden as we speak ge-fine-tuned.
Ik vind het leuk om hobbymatig te ontwikkelen en er vervolgens niks mee kunnen doen haha..
Wel ontzettend bedankt voor jullie (vooral Thomas) effort, ik hoop dat je de code wellicht zelf ooit nog kan gebruiken.
Thomas - 31/03/2016 13:43 (laatste wijziging 31/03/2016 13:47)
Moderator
EDIT: even terugkomend op die SQL code, het enige punt wat ik eigenlijk over probeerde te brengen is dat de queries "hardcoded" zouden moeten zijn. Je wilt een applicatie installeren. Het staat al vast uit welke tabellen deze bestaan. De queries voor het creëren van die tabellen liggen daarmee ook vast. Dit is dus niet iets waar een gebruiker invloed op zou mogen uitoefenen. In het algemeen is het verstanding om gebruikers weg te houden van het manipuleren van de structuur van je data, vaak zijn deze enkel bezig met de manipulatie van de inhoud van de data zelf.
---
Geen probleem.
Het lijkt ook allemaal veel en ingewikkeld, maar als je code ziet die op een compleet andere manier (en mogelijk "moeilijker") geschreven is dan je gewend bent, dan moet zoiets ook een beetje groeien.
Er zijn legio manieren om een probleem (oa het schrijven van een installer) te tacklen, dit is er slechts één van. Je hoeft ook niet in 1x te (kunnen) doorgronden wat dit allemaal doet, maar je zou er bij tijd een wijlen eens naar terug kunnen keren, mogelijk is het ook een kwestie van gewenning en op den duur herkenning.
Wat je ook zou kunnen doen is de dingen die je kunt gebruiken lenen, of in ieder geval de principes die gehanteerd worden ter harte nemen:
- scheid de verschillende acties (het weergeven van een formulier, het verwerken van een formulier et cetera) volgens het POST/redirect/GET principe, op deze manier heb je een verdeel-en-heers strategie wat het makelijk maakt je applicatie te ontwikkelen en te debuggen; toegegeven, je introduceert wel wat overhead omdat je mogelijk eerdere formulierinvoer moet onthouden in een sessie omdat je het weergeven en verwerken uit elkaar hebt getrokken, maar "in the long run" is dit toch vele malen makkelijker in het gebruik en is de navigatie voor de gebruiker prettiger (geen dubbelposts en/of dialogen die vragen of gegevens opnieuw verstuurd moeten worden)
- zorg dat als het de bedoeling is dat een webpagina wordt getoond, dat dit altijd een volledig en kloppend HTML document is
- zorg ervoor dat door je hele applicatie (bronbestanden (dus de broncode), output (zoals HTML documenten), de database-connectie, de database-tabellen en last but certainly not least de DATA in deze tabellen) gebruik maakt van eenzelfde character encoding; het vergeten van het selecteren van een character encoding bij het maken van een databaseconnectie kan enkele maanden/jaren down the line als een applicatie in gebruik is voor forse hoofdpijn zorgen als DATA in je database niet in de juiste character encoding blijkt te zijn opgeslagen
- toch zou ik een begin proberen te maken met OOP; ook ik was meer een persoon die van procedurele code hield, maar op den duur begin je toch wel de voordelen van OOP te zien waarschijnlijk; zo zijn bepaalde problemen makkelijker op te lossen met een OOP structuur in vergelijking met een procedurele structuur, daarnaast leer je code te bundelen die soortgelijke dingen doen en schrijf je meer en meer uit oogpunt van modulaire brokken functionaliteit die ook herbruikbaar zijn; ik ben echter geen OOP zealot, het hoeft niet (niet altijd, althans) per se in OOP gemaakt te worden, PHP is per slot van rekening een hybride taal dus je hebt nog steeds de keuzevrijheid; OOP is ook geen doel, maar een middel; ik zou OOP wel een kans geven, al was het maar een eenvoudige eerste verkenning; vandaag de dag wordt ook steeds meer code in OO stijl geschreven, dus het loont de moeite om je toch enigszins te verdiepen in deze materie, het is een potentieel extra stuk gereedschap in je toolkit; en al gebruik je een cirkelzaag veel minder vaak dan je vaste breekijzer, is het nog steeds de moeite waard om te weten wat voor ding het is en wat je er (potentieel) mee kunt doen
Sinds 3 jaar pak ik PHP weer op, ben het gelukkig niet verleerd, wel zijn er een functies en de bijbehorende parameters die ik weer even op moet zoeken. Een week gelden kon ik data via een form toevoegen, wijzigen en verwijderen, data samenvoegen en de basis aan statementen (PHP). Nu kom ik weer op het punt dat ik de input ook op patronen kan herkennen (lees: simpele reg-exp's) en de iets wat complexere codes.
3 jaar geleden begon ik aan een forum en was ik alleen maar client-side bezig om de boel zo mooi mogelijk te stylen en gebeurden er niks dynamisch. Daarom vind ik het wel leuk om het nu op een andere tour te gooien. Met hulp van SiMa en php.net kom ik een eind.
Nu ik de nadruk van mijn hobbymatige project op server-side gooi zie ik inderdaad in dat ik veel code (te veel) onnodig dupliceer, ik zie ook wel echt de meerwaarde in van een goeie error handler of formulieren class met validatie.
Ik heb de afgelopen maanden ook geproefd van cakePHP en Zend (1). Het is een chaos als je niet weet waar je moet zijn voor een error als je 'gewone' code gewend bent. Het is ontzettend veel zoeken en proberen. Wat ik wel fijn vond is de scheiding tussen HTML/CSS/JS en PHP+SQL het is wel heel schoon werken.
Na dit project zal ik proberen om een zinvolle class te schrijven wat ook direct een meerwaarde is, de rede dat ik dit zeg is omdat ik ook mensen een SQL class heb zien schrijven waarvan de syntax voor SQL commando's anders is, dat slaat natuurlijk nergens op om je structuur van je query te wijzigen maar qua functionaliteiten of hoeveelheid karakters er niet op vooruit te gaan.
Ik geloof er wel in, ook omdat bij mijn huidige simpele project kende ik opstart problemen. Niet erg om vanaf 0 te beginnen maar als er al een basis is waar je op door kan gaan is dat reten efficient natuurlijk.
Om te beginnen ga ik me verdiepen in SQL - tabellen en wijze van opslaan in het type DB.
...de rede dat ik dit zeg is omdat ik ook mensen een SQL class heb zien schrijven waarvan de syntax voor SQL commando's anders is, dat slaat natuurlijk nergens op om je structuur van je query te wijzigen maar...
Dit kan een meerwaarde hebben als het een soort abstractielaag is die je in staat stelt om op die manier "database onafhankelijke queries" te schrijven. Je bent dan meer met modellen bezig (ORM) dan met (My)SQL. Dit wordt ook wel een DAL (Database Abstraction Layer) genoemd. Hiermee verkrijg je een hoop flexibiliteit die mogelijk ook benut kan worden als de rest van je applicatie hier op inspeelt, maar anders is dit een hoop "dead weight".
Trouwens het schrijven van een (semi) simpele wrapper om standaard database-functionaliteit kan nog steeds een zekere meerwaarde hebben.
Citaat:
Om te beginnen ga ik me verdiepen in SQL - tabellen en wijze van opslaan in het type DB.
Dit is altijd leerzaam. Indien je gebruik maakt van MySQL zijn er vanuit PHP in principe twee manieren om hiermee te communiceren: PDO en MySQLi. Misschien zal ik nog eens een nieuwe tutorial schrijven over PDO.
Qua storage engines zijn er niet zoveel keuzes denk ik, meestal wil je -bij relationele database- gebruik maken van InnoDB, en anders van MyISAM.
En dan moet je ook enigzins nadenken over hoe je omgaat met character encoderingen. Dit laatste blijft niet beperkt tot enkel databases maar komt in alle facetten (HTML, JavaScript, PHP, databases) terug.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
