[PHP/(My)SQL] voor dummies - Deel 44

quote:

Op donderdag 31 mei 2007 13:18 schreef Hmail het volgende:
Als ik het goed begrijp wil je nu Apache en IIS naast elkaar laten draaien? Dan is het niet zo gek dat die dwars met elkaar gaan liggen.

Ik zou eerst een keuze maken: Of Apache, of IIS. Als je voor Apache gaat, IIS eraf gooien, ga je voor IIS, Apache eraf. Dat scheelt alvast een hoop troubleshooten

Gewoon allebij op een apparte poort draaien lijk mij ...

quote:

Op donderdag 31 mei 2007 13:36 schreef Tuvai.net het volgende:
Maar goed, volgende probleem. stel ik wil voor MySQL een gebruiker aanmaken, die we voor het gemak effe 'pietje' noemen, deze heb ik zojuist toegevoegd en alleen maar de privileges gegeven om data en structuur te beheren, géén administratieve privileges dus. Gebruiker heb ik op die manier toevoegen en ik kan ook al als die gebruiker inloggen. Echter, ik blijf als die gebruiker, die maar beperkte rechten zou moeten hebben, bijvoorbeeld de 'mysql' database zien; ook kan ik als die gebruiker andere gebruikers wijzigen, wat natuurlijk niet de bedoeling is. Help?

Ik ben ook niet zo heel erg thuis met phpMyAdmin, maar je kunt gebruikers rechten geven op een specifieke database. Dat betekent wel dat je eerst alle rechten weer even weg moet halen, en dan per database op moet geven welke rechten hij hiervoor heeft. Het is even knutselen, maar ik heb het pas nog werkend gekregen, dus ik kan wel even uitvogelen hoe het precies zit als je wilt

quote:

Op donderdag 31 mei 2007 13:36 schreef WyriHaximus het volgende:

[..]

Gewoon allebij op een apparte poort draaien lijk mij ...

Dat kan, maar of het nuttig is is maar de vraag. Als je gewoon wat wil knutselen met php en mysql, dan heeft het niet zoveel zin om daar ook nog eens een aparte webserver naast te gaan draaien.
Als je echt een professionele webserver wilt draaien, met diverse sites (php, asp, noem maar op), dan is het misschien iets om over na te denken.

Je hoort mij ook niet zeggen dat het niet naast elkaar kan draaien. Het heeft alleen geen nut als je gewoon wat wil prutsen met php.

En sowieso, waarom zou je uberhaupt 2 webservers naast elkaar willen draaien Het kan misschien wel, maar ik zie er echt geen nut van in.

Ik heb gebruiker 'pietje' nu alle rechten ontnomen (niks aangevinkt) maar wel op één specifieke tabel rechten gegeven, het is dus de bedoeling dat gebruiker 'pietje' maar één database krijgt. Dat doet het ook.

Probleem is echter dat ik wel tabel 'information_schema' blijf zien als ik als 'pietje' in log, terwijl ik hier niks specifieks voor heb ingesteld.

quote:

Op donderdag 31 mei 2007 13:42 schreef Hmail het volgende:

[..]

Dat kan, maar of het nuttig is is maar de vraag. Als je gewoon wat wil knutselen met php en mysql, dan heeft het niet zoveel zin om daar ook nog eens een aparte webserver naast te gaan draaien.
Als je echt een professionele webserver wilt draaien, met diverse sites (php, asp, noem maar op), dan is het misschien iets om over na te denken.

Dan kan je dat ook gewoon allemaal onder apache draaien dacht ik. Weet het niet zeker werk nooit met ASP .

quote:

Op donderdag 31 mei 2007 13:55 schreef Tuvai.net het volgende:
Ik heb gebruiker 'pietje' nu alle rechten ontnomen (niks aangevinkt) maar wel op één specifieke tabel rechten gegeven, het is dus de bedoeling dat gebruiker 'pietje' maar één database krijgt. Dat doet het ook.

Probleem is echter dat ik wel tabel 'information_schema' blijf zien als ik als 'pietje' in log, terwijl ik hier niks specifieks voor heb ingesteld.

Wat voor type user is het? Dat kun je in PHPMyAdmin checken onder Database->Privileges. In mijn geval is het een Database-specific user. Check dat even

quote:

Op donderdag 31 mei 2007 14:04 schreef WyriHaximus het volgende:

[..]

Dan kan je dat ook gewoon allemaal onder apache draaien dacht ik. Weet het niet zeker werk nooit met ASP .

Ik werk ook niet met ASP, en ik heb het (thank god) nog nooit werkend hoeven te krijgen onder Apache, maar het schijnt niet makkelijk te zijn. Daarom kies ik ook liever voor een combinatie IIS & PHP dan Apache & ASP. Gewoonweg omdat er meer mensen IIS en PHP werkend willen hebben dan Apache en ASP. (dit kan ik uiteraard niet gehinderd door enige kennis van zaken makkelijk zeggen, ik weet de specifieke aantallen niet)

quote:

Op donderdag 31 mei 2007 14:25 schreef Hmail het volgende:

[..]

Ik werk ook niet met ASP, en ik heb het (thank god) nog nooit werkend hoeven te krijgen onder Apache, maar het schijnt niet makkelijk te zijn. Daarom kies ik ook liever voor een combinatie IIS & PHP dan Apache & ASP. Gewoonweg omdat er meer mensen IIS en PHP werkend willen hebben dan Apache en ASP. (dit kan ik uiteraard niet gehinderd door enige kennis van zaken makkelijk zeggen, ik weet de specifieke aantallen niet)

* WyriHaximus sluit zich hier volledig bij aan

quote:

Op donderdag 31 mei 2007 14:23 schreef Hmail het volgende:

[..]

Wat voor type user is het? Dat kun je in PHPMyAdmin checken onder Database->Privileges. In mijn geval is het een Database-specific user. Check dat even

Bij database specifieke rechten stond alleen de tabel die de gebruiker 'pietje' ook daadwerkelijk mag gebruiken. Deze heb ik voor te testen even weggehaald, met als resultaat dat wanneer je als 'pietje' inlogt, nu alléén maar database information_schema ziet. Verder staat er bij database specifieke rechten niets.

EDIT: Ook al geprobeerd de gebruiker te verwijderen en opnieuw toe te voegen, met alleen hetzelfde resultaat. :/

Nog een edit: Als ik bij databases ga kijken bij het schermpje Gebruikers die toegang hebben tot "information_schema" dan staat gebruiker 'pietje' hier ook echt niet bij, zoals bij de rest van de tabellen die wél netjes verborgen worden, wel het geval is.

[ Bericht 10% gewijzigd door Tuvai.net op 31-05-2007 14:57:54 ]

In mijn geval ziet het database-privleges scherm er zo uit. Het gaat om de gemaskeerde naam:

quote:

Op donderdag 31 mei 2007 15:07 schreef Hmail het volgende:
In mijn geval ziet het database-privleges scherm er zo uit. Het gaat om de gemaskeerde naam:
[afbeelding]

Dat heb ik ook staan bij de betreffende database waar de betreffende user wél toegang toe moet hebben. Maar bij 'information_schema' staat niks verdachts, toch is deze gewoon toegankelijk door de betreffende user terwijl dat niet de bedoeling zou moeten zijn.

Het beheerscherm van de user-privileges op de mysql-server. Misschien dat daar iets anders is?

INFORMATION_SCHEMA is een speciale database waarvan de inhoud verandert aan de hand van de rechten die de gebruiker heeft. Die blijf je dus altijd zien, is sinds MySQL 5 als ik me niet vergis

Wat is dan de functie van die database als je die toch (niet kan) gebruik(t/en)...

verdorie, je hebt gelijk
Inderdaad, ik heb ook een information_schema, sorry

quote:

Op donderdag 31 mei 2007 15:51 schreef JeRa het volgende:
INFORMATION_SCHEMA is een speciale database waarvan de inhoud verandert aan de hand van de rechten die de gebruiker heeft. Die blijf je dus altijd zien, is sinds MySQL 5 als ik me niet vergis

Verrek, dat heb ik ook nog gelezen ook nog. Ik bleef het toch proberen omdat mijn webhost die database niet doet weergeven, maar ik zie nu pas dat die nog op een MySQL 4.x.x versie draait.

Nou ja, in ieder geval draait alles nu. Ik zal uiteraard nog wat gaan spelen met de configuratie zodat ik ook zie hoe PHP vanaf de serverkant werkt. Ben in ieder geval blij dat 't nu loopt.

quote:

Op donderdag 31 mei 2007 16:05 schreef Chandler het volgende:
Wat is dan de functie van die database als je die toch (niet kan) gebruik(t/en)...

Je kunt hem wel gebruiken, en INFORMATION_SCHEMA geeft informatie over je rechten, databases, tabellen, etcetera het is een alternatief voor de niet-standaard SHOW-syntax.

Vandaag ben ik verder met een usersysteem gegaan, en vroeg mij af of de volgende methode veilig is:

De user probeert in te loggen. Ik vang de $_POST op, encrypt het password direct naar md5, en stuur het naar de functie checkLogin.

checkLogin():
Als de username en het password matchen met de database:
-De sessie variabele UsernameSession en PasswordSession aanmaken en invullen.
-Een cookie met een random string wordt gezet.
-Dezelfde random string en het IP-adres van de gebruiker in de database zetten.
-Inloggen.

--------------

Of: De user komt terug, en heeft een cookie meegenomen:

checkCookie()
Als de random string in de cookie en het IP-adres van de gebruiker matchen met de database:
-De sessie variabele UsernameSession en PasswordSession aanmaken en invullen.
-Inloggen.

--------------

De user opent een pagina, de functie checkCredentials wordt aangeroepen.

checkCredentials()
Kijkt of de username en password uit de sessie gecombineerd met het IP-adres van de gebruiker in de database aanwezig is, zo ja:
-UserID en Userlevel teruggeven

Tussentijdse passwordwijzigingen, of een wijziging in userlevel, wordt hier mee opgevangen.

--------------


Misschien ga ik de unieke key in de cookie nog een timeout geven (databaseveld), om het extra hufterproof te maken. Dit systeem lijkt mij aardig veilig?

Waarom sla je de username/password op in de sessie? Het lijkt mij dat alleen een userID voldoende is. Daarnaast lijkt het mij verstandig om het IP uit de cookie te laten, die kun je opvragen met $_SERVER['REMOTE_ADDR']. Zo voorkom je dat een cookie gestolen word, en vanaf een ander IP aangepast en misbruikt word

Het IP adres haal ik uiteraard uit REMOTE_ADDR, daar had ik aan gedacht.

Wat het userid betreft, daar had ik eigenlijk totaal nog niet aan gedacht. Meer vanuit een menselijke denkwijze dacht ik er zelf meer aan het username / password te laten onthouden, zoals je dat zelf ook zou doen. Een goede tip, bedankt

je kunt wel een hash maken waarbij je de username + ip + id hasht.. deze controlleer je dan weer met de usernaam + $_SERVER['REMOTE_ADDR'] + id oid..

Zat mogelijkheden

quote:

Op donderdag 31 mei 2007 20:46 schreef Chandler het volgende:
je kunt wel een hash maken waarbij je de username + ip + id hasht.. deze controlleer je dan weer met de usernaam + $_SERVER['REMOTE_ADDR'] + id oid..

Zat mogelijkheden

Ik ben niet bekend met hashen, maar je zet deze vijf variabelen tot een lange string tekst om, wat je vervolgens weer terugdecodeerd naar vijf losse variabelen?

quote:

Op donderdag 31 mei 2007 20:46 schreef Chandler het volgende:
je kunt wel een hash maken waarbij je de username + ip + id hasht.. deze controlleer je dan weer met de usernaam + $_SERVER['REMOTE_ADDR'] + id oid..

Zat mogelijkheden

Waarna de "hacker" vervolgens een hash maakt van de username + ip + id van "het slachtoffer" hasht, en vervolgens dus niet eens de moeite hoeft te doen voor het stelen van een cookie

Serieus, je moet geen gegevens die te achterhalen zijn gaan achterlaten in een hash, of je moet er een hash overheen halen met een willekeurig iets. Zo'n hash moet altijd random zijn, en niet na te maken door de user. Je moet er eigenlijk van uit gaan dat de potentiële hacker alles al weet. Van jou weet ik bijvoorbeeld al je username en id. Ik zet mijn ip in de var, en hebbes, ik heb adminrechten. You see?
Je kunt het wel een beetje afdekken door die var in de database te zetten, maar dan ben je dus het ene lek met het andere aan het dichten. Random is the keyword.

quote:

Op donderdag 31 mei 2007 20:51 schreef Geqxon het volgende:

[..]

Ik ben niet bekend met hashen, maar je zet deze vijf variabelen tot een lange string tekst om, wat je vervolgens weer terugdecodeerd naar vijf losse variabelen?

Exact. Iets a la:

Je krijgt dat een variabele waar de meeste users geen kaas van hebben gegeten, en gokken hoe het word opgebouwd is lastig. Maar daar moet je niet op vertrouwen, want als ik dit weet, zet ik gewoon md5('Chandler'.'6897'.'127.0.0.1') (waarbij we dan even aannemen dat dat mijn ip is), en dat zet ik in mijn cookie neer. Voila, adminrechten

[ Bericht 39% gewijzigd door Hmail op 31-05-2007 21:32:14 ]