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

maak een array van alle tags, loop door alle tags met een while of een foreach en duw de matches in een array. klaar

zie bijvoorbeeld http://nl3.php.net/manual/en/function.preg-match-all.php de reactie van rickyale at ig dot com dot br

[ Bericht 48% gewijzigd door Juggernaut op 19-04-2005 12:45:39 ]

quote:

Op dinsdag 19 april 2005 11:07 schreef markvleth het volgende:

[..]

Dat heb ik uiteraard, Object georienteerd programmeren is voornamelijk classificeren.
Net zoals in bijvoorbeeld het dierenrijk. We hebben de classificatie Warmbloedigen en een daarvan afgeleide classificatie zou bijvoorbeeld katachtigen kunnen zijn. Katachtigen is een uitbreiding op warmbloedigen. En dan zien we gelijk een voordeel. We hoeven de classificatie niet nogmaals te schrijven, we breiden deze enkel uit. Het is dus een vorm van gestructureerd programmeren, niets meer niets minder.

Mooi verhaal, snap het ook nog maar ik ben feitelijk op zoek naar iets pragmatischer.

Daar lijken me genoeg voorbeelden van te vinden op het grote internet. Het belangrijkste is het classificeren onder de knie te krijgen. Dus welke methodes en attributen behoren nou toe aan een bepaalde klasse? Voor entiteiten is dit vrij simpel, dit is immers een weerspiegeling van de werkelijkheid en vaak de onderliggende database. Dus bijvoorbeeld een class User zal attributen hebben als name, age, etc. Verder heeft zo'n klasse methode nodig om de attributen te kunnen wijzigen danwel opvragen. dit zijn de zogenaamde getters en setters. Zulke entieiten/classes zul je dus voor elk database tabelletje hebben.

Lastiger wordt het classificeren als we bijvoorbeeld een UserManager class definieren. Dergelijke klasses zijn verantwoordelijk voor het selecteren/muteren/verwijderen van entiteiten in de persistentie laag (vaak een database). Dus zulke klasses hebben methodes als findByName($name), store($user), etc...

Zoals je ziet heeft dit alles met structuur te maken en het neerleggen van verantwoordelijkheden. Wil ik een andere persistentie laag gebruiken dan hoef ik nu enkel de betreffende Manager klasses te wijzigen. Alle lagen daarboven blijven hetzelfde. Het plaatje is natuurlijk veel groter maar als je dit correct weet te implementeren ben je al heel ver...

quote:

Op dinsdag 19 april 2005 12:38 schreef Juggernaut het volgende:
maak een array van alle tags, loop door alle tags met een while of een foreach en duw de matches in een array. klaar

zie bijvoorbeeld http://nl3.php.net/manual/en/function.preg-match-all.php de reactie van rickyale at ig dot com dot br

Dat doe ik al maar


Vindt nu alleen [img] en [/img] Ik wil graag dat hij ook [rimg] en [limg] vind en daarvoor moet ik de regilier expression aanpassen en ik kom er niet uit hoe ik die moet aanpassen.....

quote:

Op dinsdag 19 april 2005 10:39 schreef markvleth het volgende:

[..]

Ik heb die link even bekeken maar er staan een hoop merkwaardige dingen in.
Ten eerste het rare idee dat je geen username (user) in je sessie zou mogen opslaan. Dat is natuurlijk de reinste onzin, dat mag wel. Of je nu aan de hand van een variabele controleert of een gebruikers is aangemeld of een volledige user maakt het risico niet groter of kleiner. Oftewel username in sessie stoppen mag wel.

Verder wordt er voorgeteld een database te gebruiken voor het langdurig aangemeld houden van personen. Ook dit is not done, het creeert juist een beveiligings risico. Een database is hier tevens niet voor bedoeld.

Wat ik doe is een deel van het ip adres met md5() encrypten en in de database en een sessie oplsaan.

Ik kontroleer dan beide, of de remote adress hetzelfde is als het opgeslagen ip in de database en in de sessie.

je doet het niet. img is bij jou een vaste waarde. Je moet door de array met tags loopen en dan elke keer img vervangen door de tag. in jouw geval loopt ie dus 3x en doet ie ook 3x de preg_match_all. bestudeer m'n link nog maar eens goed.

quote:

Op dinsdag 19 april 2005 14:21 schreef Darkomen het volgende:
Ik kontroleer dan beide, of de remote adress hetzelfde is als het opgeslagen ip in de database en in de sessie.

Kun je me dan uitleggen waarom je dergelijke gegevens persistent wilt maken? Is het echt noodzakelijk dat een sessie een eventuele server crash overleeft?

Is het niet handiger om beide gegevens gewoon in de sessie te houden?

Ik wilde er zeker van zijn dat degene die inlogt het juiste ip adres heeft, dus dat het niet mogenlijk is en de sessie te kapen en de het ip te 'spoofen' (zo heet dat volgens mij) is

Je kunt toch niet zomaar gegevens in je sessie wijzigen?

quote:

Op dinsdag 19 april 2005 10:39 schreef markvleth het volgende:

[..]

Ik heb die link even bekeken maar er staan een hoop merkwaardige dingen in.
Ten eerste het rare idee dat je geen username (user) in je sessie zou mogen opslaan. Dat is natuurlijk de reinste onzin, dat mag wel. Of je nu aan de hand van een variabele controleert of een gebruikers is aangemeld of een volledige user maakt het risico niet groter of kleiner. Oftewel username in sessie stoppen mag wel.

Verder wordt er voorgeteld een database te gebruiken voor het langdurig aangemeld houden van personen. Ook dit is not done, het creeert juist een beveiligings risico. Een database is hier tevens niet voor bedoeld.

Hoe zorg ik dan voor het langdurig aangemeld houden van personen?

met behulp van je sessie natuurlijk, je kunt de geldigheidsduur van je sessie toch instellen, of bedoel je dingen als "keep me logged in"

quote:

Op dinsdag 19 april 2005 15:31 schreef markvleth het volgende:
met behulp van je sessie natuurlijk, je kunt de geldigheidsduur van je sessie toch instellen, of bedoel je dingen als "keep me logged in"

jup. Als ik ingelogd wil blijven gedurende een hele sessie is dat het probleem niet. Er kan een vinkje gezet worden bij het inloggen zodat de betreffende user ingelogd blijft. Ik doe dat nu dmv een tabel waarin ip,userid en een randomwaarde worden opgeslagen, waarvan de randomwaarde ook in de cookie van de gebruiker staat. Deze cookie is dan gewoon geldig tot het einde der tijden . Bij het uitloggen kunnen mensen dan ook kiezen voor 'deze client uitloggen' 'alle clients uitloggen' etc. net als bij fok!.

quote:

Op dinsdag 19 april 2005 15:15 schreef markvleth het volgende:
Je kunt toch niet zomaar gegevens in je sessie wijzigen?

Ik had begrepen dat sessies te kapen waren?
Zie die link helemaal bovenaan.
Dus stel dat iemand die sessie kaapt en ik mbv die sessie info opvraag zou iemand dus misbruik kunnen maken?

quote:

Op dinsdag 19 april 2005 15:36 schreef DionysuZ het volgende:
jup. Als ik ingelogd wil blijven gedurende een hele sessie is dat het probleem niet. Er kan een vinkje gezet worden bij het inloggen zodat de betreffende user ingelogd blijft. Ik doe dat nu dmv een tabel waarin ip,userid en een randomwaarde worden opgeslagen, waarvan de randomwaarde ook in de cookie van de gebruiker staat. Deze cookie is dan gewoon geldig tot het einde der tijden . Bij het uitloggen kunnen mensen dan ook kiezen voor 'deze client uitloggen' 'alle clients uitloggen' etc. net als bij fok!.

Maar dat betekend dat die sessie dan nog steeds even kaapbaar is als domweg het wachtwoord aan client kant op te slaan in een cookie, het enige voordeel is dat het wachtwoord(md5) van de gebruiker niet over is gestuurd. Maar daarvoor bevuil je wel je db. Geen goede oplossing dus..

quote:

Op dinsdag 19 april 2005 15:41 schreef Darkomen het volgende:
Ik had begrepen dat sessies te kapen waren?
Zie die link helemaal bovenaan.
Dus stel dat iemand die sessie kaapt en ik mbv die sessie info opvraag zou iemand dus misbruik kunnen maken?

Iemand kan niet zomaar de variabelen in de sessie wijzigen. Het kapen van een sessie wil dus niet zeggen dat je niet meer kunt controleren op ip, komt het ip in de sessie niet overeen met het ip van de huidige aanvraag dan is het eventueel een poging tot kaping...

Oke dan zou ik het niet op hoeven te slaan dus, maar niet echt verkeerd dus
Tnx, ik haal het wel weg, scheelt weer info in de db

quote:

Op dinsdag 19 april 2005 15:46 schreef markvleth het volgende:

[..]

Maar dat betekend dat die sessie dan nog steeds even kaapbaar is als domweg het wachtwoord aan client kant op te slaan in een cookie, het enige voordeel is dat het wachtwoord(md5) van de gebruiker niet over is gestuurd. Maar daarvoor bevuil je wel je db. Geen goede oplossing dus..

Tweede voordeel is dat slechts 1 ip geldig is voor die code en als iemand dus die code onderschept er weinig mee kan aangezien hij ook nog het ip moet hebben. Als iemand een wachtwoord onderschept of een hash van een wachtwoord kan hij daar veel meer mee. Maar als het geen goede oplossing is, hoe moet ik het dan doen? Wil graag een goed beveiligde website.

quote:

Op dinsdag 19 april 2005 14:21 schreef Darkomen het volgende:

[..]

Wat ik doe is een deel van het ip adres met md5() encrypten en in de database en een sessie oplsaan.

Ik kontroleer dan beide, of de remote adress hetzelfde is als het opgeslagen ip in de database en in de sessie.

En hoe doe je;
Logged in as $username
Of, welkom $username
Steeds de username opvragen bij elke hit ?
Ik stop het gewoon in een sessie ...

quote:

Op dinsdag 19 april 2005 16:07 schreef DionysuZ het volgende:
Tweede voordeel is dat slechts 1 ip geldig is voor die code en als iemand dus die code onderschept er weinig mee kan aangezien hij ook nog het ip moet hebben. Als iemand een wachtwoord onderschept of een hash van een wachtwoord kan hij daar veel meer mee. Maar als het geen goede oplossing is, hoe moet ik het dan doen? Wil graag een goed beveiligde website.

Die ip controle voer je ook uit zonder dat je nieuwe codes verzint, dus van een tweede voordeel is al geen sprake. Als je het goed beveiligd wil hebben doe je alles over https en biedt je geen faciliteiten tot het ingelogd blijven (iig niet aan admins)...

https is niet beschikbaar helaas. Ik vraag me af hoe bijv. fok! het doet of phpbb

Ik sla verjaardagen als een timestamp op in een tabel, nu wil ik ze laten sorteren op de verjaardag en niet op geboortedag

ORDER by user_birthday ASC

dit werkt niet goed omdat de geboortejaar mee wordt genomen. zo komt 1-05-1983 voor 28-04-1986 en dat moet natuurlijk niet.
hoe kan ik dus sorteren op zoiets als user_birthday/user_birthay-year zodat er wordt gesorteerd op de dag en de maand en niet meer op jaar.

waarschijnlijk niet handig genoeg gezien de druk die op db komt te staan.

quote:

Op dinsdag 19 april 2005 19:03 schreef danko het volgende:
Ik sla verjaardagen als een timestamp op in een tabel, nu wil ik ze laten sorteren op de verjaardag en niet op geboortedag

ORDER by user_birthday ASC

dit werkt niet goed omdat de geboortejaar mee wordt genomen. zo komt 1-05-1983 voor 28-04-1986 en dat moet natuurlijk niet.
hoe kan ik dus sorteren op zoiets als user_birthday/user_birthay-year zodat er wordt gesorteerd op de dag en de maand en niet meer op jaar.

Kijk eens naar de datum en tijd functies van MySql. Converteer de timestamp naar een datum, haal er dan de maand en day uit. Daar kan je op sorteren.

Dit zou ook wel eens kunnen werken, maar misschien dat het ronde de jaarwisselingen of 28/29 februari net mis gaat.



(31556926 is het aantal seconden in een jaar )

[ Bericht 23% gewijzigd door SuperRembo op 19-04-2005 19:20:41 ]

quote:

Op dinsdag 19 april 2005 19:14 schreef SuperRembo het volgende:Converteer de timestamp naar een datum, haal er dan de maand en day uit. Daar kan je op sorteren.

kan dit direct in de eerste query al gebeuren? dus al meteen bij het uitlezen van de gegevens en niet achteraf dmv een array?

quote:

Op dinsdag 19 april 2005 19:20 schreef danko het volgende:

[..]

kan dit direct in de eerste query al gebeuren? dus al meteen bij het uitlezen van de gegevens en niet achteraf dmv een array?

Het zijn MySql functies, die worden dus door MySql uitgevoerd in een query.