[PHP] Het ontwikkelen van een forum

[Enlightenment]

Hoi.

Ik ben bezig met een eigen forum aan het schrijven in PHP. Na 2 nachtjes (jaja het ging lekker) heb ik de basisfunctionaliteit aan de praat: plaatsen van berichten, openen van topics, editen van posts en wat kleine dingetjes zijn allemaal werkend. Alleen nog geen beheerderspaneel en geen moderator-functies zoals topic sluiten / naam veranderen en bannen.

Test-forum: http://www.fluffles.net/forum

Het mooie aan mijn forum:

• Geïntegreerd in de layout; toegankelijk en conform
• Geen aparte registratie voor forum en website, maar één account voor beide onderdelen
• Schone code en geen vB brakheid
• Veel functionaliteit vergelijkbaar met GoT React (in de toekomst dan)

Waarschijnlijk ga ik het forum vrijgeven onder de GPL. De naam die ik wilde, Ferox, is helaas al in gebruik op SourceForge.

Ik voorzie wel enkele problemen, zoals een post parser. Dus het omzetten van allerlei tags naar HTML, maar de rest wel door een htmlentities() filter halen om zo XHTML compliance te garanderen. Dat vind ik wel lastig, voornamelijk omdat ik weinig kennis heb van regular expressions. Veiligheid, functionaliteit en snelheid zijn kernpunten bij zo'n parser. Weet iemand van een Open Source parser? Of misschien kan ik de phpbb parser jatten/aanpassen.

Tips, commentaar etc. zijn gewenst.

En dit is dus geen sitecheck. Het gaat niet om mijn site of mijn forum, maar de forumsoftware in het algemeen.

Ik mag hopen dat je van tevoren een degelijk ontwerp hebt gemaakt en goed hebt nagedacht over de te wensen functionaleit en gegevens die je wilt bewaren en laten zien.
En uiteraard ben je begonnen met de beveiliging...

[Enlightenment]

Ja SQL is veel uitgebreider dan nu zichtbaar is. Qua database zit het wel redelijk goed in elkaar denk ik.

Ik doe aan enige redundantie, zoals bij de topiclijst de topicstarter als string opslaan en niet als userid. Dat laatste brengt veel meer load met zich mee, omdat per topic dan de username moet worden gevonden, of je moet een join doen maar ook dat zal sterk vertragen vrees ik.

Verder gebruik ik flags om uitbreiding mogelijk te maken. Bijvoorbeeld een C-flag van een topic kan de toestand Closed aanduiden. Of H-flag voor Hidden. Etc.

De forums zijn recursief, dus je kunt subsubsubsubsubforums hebben, allemaal genest. Een forum met een C-flag gedraagt zich als een categorie, dus geen posting en geen link. Denk maar aan de forumindex van s.com.

Maar dit is mijn eerste probeersel, misschien zie ik dingen over het hoofd, en juist in het begin is het goed om te zorgen voor een goed design; een stevig fundament voor een forum dat ik goed kan uitbouwen.

[Enlightenment]

Wat betreft zoeken:

Ik kan natuurlijk gewoon een fulltext search doen, maar die zijn erg database-intensief. Ik heb gezien dat phpbb dit oplost door in een aparte tabel elk woord te linken naar topics/posts die dat woord bevatten. Is dat de beste manier? Lijkt mij omslachtig. Moet je ook weer verwijderen als je een topic verwijdert of je post aanpast ofzo. Brrr.

Enlightenment schreef op 19-01-2005 @ 11:32 :
Wat betreft zoeken:

Ik kan natuurlijk gewoon een fulltext search doen, maar die zijn erg database-intensief. Ik heb gezien dat phpbb dit oplost door elk woord in een aparte tabel te gooien en te linken naar topics. Is dat de beste manier? Lijkt mij omslachtig. Moet je ook weer verwijderen als je een topic verwijdert of je post aanpast ofzo. Brrr.

Soms is redundantie goed voor performance Het is veel makkelijker een index aan te leggen op basis van 1 woord ipv een heel bericht.

Als je je verwijzingen goed aanlegt, kun je een cascade delete doen.

Maar of het de allerbeste manier is, weet ik eerlijk gezegd ook niet.

[Enlightenment]

******** schreef op 19-01-2005 @ 11:40 :
Soms is redundantie goed voor performance Het is veel makkelijker een index aan te leggen op basis van 1 woord ipv een heel bericht.

Als je je verwijzingen goed aanlegt, kun je een cascade delete doen.

Maar of het de allerbeste manier is, weet ik eerlijk gezegd ook niet.

Wat bedoel je met cascade delete? En hoe zorg ik dat deze 'index' consistent blijft als iemand een topic verwijdert of zijn post aanpast, etc.?

Ik heb ook ooit een forum gemaakt, erg leerzaam

Denk iig goed na over een template systeem.
Dit is erg makkelijke (cq belangrijk) voor bredere inzetbaarheid

Eventuele extra functies:
Avatars
Edit -> datum (heb je al) naam en reden.
Edit en quick reply etc weghalen al je geen rechten hebt
Topic views
PM


Dit waren dingen die ik erin had gebouwd...

Enlightenment schreef op 19-01-2005 @ 11:41 :
Wat bedoel je met cascade delete? En hoe zorg ik dat deze 'index' consistent blijft als iemand een topic verwijdert of zijn post aanpast, etc.?

Stel dat je in de lijst met zoekwoorden verwijst naar het bericht (post_id kan bijv vreemde sleutel zijn naar je post tabel). Een cascade delete zorgt er dan voor dan dat alle records in de zoekwoorden tabel staan die verwijzen naar een bericht, door het DBMS mee worden verwijderd op het moment dat je het bericht verwijderd. Daar hoef jij dan niets meer aan te doen verder.

(zie Foreign Key Constrains in MySQL.. ON DELETE CASCADE)

Voor UPDATE kun je misschien met een trigger werken, maar dat werkt pas sinds MySQL 5.x.

[Enlightenment]

@ ********

Dingen zoals foreign key constraints heb ik me nooit in verdiept. MySQL 5.0 is nog lang niet production/stable, 4.1 is dat net geworden. Dat is toch voor mij de drempel om het te gebruiken.

@ **********

Zijn goede punten, alhoewel ik sommigen al bedacht heb. Er zit veel in mn hoofd qua kleine handigheden, dat kan ik nu mooi gaan implementeren.

PM zal functionaliteit van het CMS zelf worden, doordat accounts niet forum-specifiek zijn. In het profiel van iemand (wat nu nog een saaie lijst is) zullen veel meer mogelijkheden gaan verschijnen waaronder PM.

Je Avatar zal voor zowel forum als frontpage gelden.

De fout die ik toen heb gemaakt is door het forum te integreren met een hoofdaccount.
Ik kon het niet meer loskoppelen waardoor ik een forum had waarop je niet meer kon registeren etc

[Dr HenDre]

Enlightenment schreef op 19-01-2005 @ 11:29 :
Ik doe aan enige redundantie, zoals bij de topiclijst de topicstarter als string opslaan en niet als userid. Dat laatste brengt veel meer load met zich mee, omdat per topic dan de username moet worden gevonden, of je moet een join doen maar ook dat zal sterk vertragen vrees ik.

dat is wel waar, maar ik denk dat je dan inlevert in functionaliteit. Op het moment dat iemand een nickchange wil, dan verdert zn nick alleen in posts/topcs na zn nickchange, alles daarvoor blijft staan. (of je moet db search doen naar topics/posts waar username bar is en dat veranderen in foo, maar dat lijkt me nog vervelender)

Enlightenment schreef op 19-01-2005 @ 12:02 :
Dingen zoals foreign key constraints heb ik me nooit in verdiept. MySQL 5.0 is nog lang niet production/stable, 4.1 is dat net geworden. Dat is toch voor mij de drempel om het te gebruiken.

Gebruik dan ook een echte database.. postgresql?

******** schreef op 19-01-2005 @ 12:08 :
Gebruik dan ook een echte database.. postgresql?

MSSQL is beter dan postgresql, maar ook stukje duurder

Enlightenment schreef op 19-01-2005 @ 11:29 :
Ja SQL is veel uitgebreider dan nu zichtbaar is. Qua database zit het wel redelijk goed in elkaar denk ik.

Dat mag ik hopen.

Enlightenment schreef op 19-01-2005 @ 11:29 :

Ik doe aan enige redundantie, zoals bij de topiclijst de topicstarter als string opslaan en niet als userid. Dat laatste brengt veel meer load met zich mee, omdat per topic dan de username moet worden gevonden, of je moet een join doen maar ook dat zal sterk vertragen vrees ik.

Nou nou. Zoveel impact heeft een join nou ook weer niet op een database. Tenzij je geen FK's en geen indexen hebt, of verschillende datatypes gebruikt waardoor er geen index gebruikt kan worden.

Enlightenment schreef op 19-01-2005 @ 11:29 :

Verder gebruik ik flags om uitbreiding mogelijk te maken. Bijvoorbeeld een C-flag van een topic kan de toestand Closed aanduiden. Of H-flag voor Hidden. Etc.

Flags zijn cool. Gebruik dan wel binary flags; is veel efficienter.

Bit0 = closed
Bit1 = Hidden

00 = visible, open
01 = visible, closed
10 = hidden, open
11 = visiblehidden, closed

etc.

Enlightenment schreef op 19-01-2005 @ 11:29 :

Maar dit is mijn eerste probeersel, misschien zie ik dingen over het hoofd, en juist in het begin is het goed om te zorgen voor een goed design; een stevig fundament voor een forum dat ik goed kan uitbouwen.

Zorg er dan voor dat je je design ook op papier hebt; niet alleen in je hoofd.

Enlightenment schreef op 19-01-2005 @ 11:32 :
Wat betreft zoeken:

Ik kan natuurlijk gewoon een fulltext search doen, maar die zijn erg database-intensief. Ik heb gezien dat phpbb dit oplost door in een aparte tabel elk woord te linken naar topics/posts die dat woord bevatten. Is dat de beste manier? Lijkt mij omslachtig. Moet je ook weer verwijderen als je een topic verwijdert of je post aanpast ofzo. Brrr.

Lijkt mij de snelste manier voor de database. Gewoon na het posten de post doorlopen en alle woorden indexeren.

********** schreef op 19-01-2005 @ 12:09 :
MSSQL is beter dan postgresql, maar ook stukje duurder

Oude Oracle versies zijn gratis te gebruiken

[Enlightenment]

Dr HenDre schreef op 19-01-2005 @ 12:07 :
dat is wel waar, maar ik denk dat je dan inlevert in functionaliteit. Op het moment dat iemand een nickchange wil, dan verdert zn nick alleen in posts/topcs na zn nickchange, alles daarvoor blijft staan. (of je moet db search doen naar topics/posts waar username bar is en dat veranderen in foo, maar dat lijkt me nog vervelender)

Ehr, enkel de informatie voor de topicstarter (te zijn bij de topiclijst in een forum) wordt plaintext opgeslagen, niet in een topic zelf. Van de posts wordt dus de userid opgeslagen en dat werkt dus prima bij een nickchange.

******** schreef op 19-01-2005 @ 12:08 :
Gebruik dan ook een echte database.. postgresql?

Traag

********** schreef op 19-01-2005 @ 12:09 :
MSSQL is beter dan postgresql, maar ook stukje duurder

Yeah right.

Nee MySQL is the way voor mij. Open Source is sowieso een vereiste. MySQL levert performance en de nieuwe versies ook aardig wat functionaliteit.

[Enlightenment]

eddie schreef op 19-01-2005 @ 12:40 :
Nou nou. Zoveel impact heeft een join nou ook weer niet op een database. Tenzij je geen FK's en geen indexen hebt, of verschillende datatypes gebruikt waardoor er geen index gebruikt kan worden.

Zal zelf nog wat benchmarken. Maar stel ik heb een grote tabbel met veel users, en een grote tabel met topics. Als ik dan een join doe, gaat dan dan niet f*cking traag? Bij een JOIN heb je sowieso een extra voorwaarde, WHERE `id` = `id`, om zo de twee tabellen te koppelen.

Flags zijn cool. Gebruik dan wel binary flags; is veel efficienter.

Mja maar dan is al vastgelegd wat elk bit doet. Flags zoals ik nu heb, zijn juist leuk omdat je later een nieuwe Z-flag erin kan proppen. Ook backwards-compatible enzo. Efficienter is misschien wel om als 2 bytes op te slaan ofzo. Dat zijn 16 bits, mwah.

Zorg er dan voor dat je je design ook op papier hebt; niet alleen in je hoofd.

Ik begon met het op papier zetten van de SQL tabellen, dat is goed gegaan en uiteindelijk aangemaakt en begonnen met de code. Verder heb ik veel kleine en minder kleine ideeen op papier gezet, en een beetje gebrainstormd.

eddie schreef op 19-01-2005 @ 12:42 :
Oude Oracle versies zijn gratis te gebruiken

Voor oude Oracle versies heb je een netware server nodig.

@Enlightenment: Ziet er puik uit. Wat voor manier om het secure te houden gebruik je?
Trouwens, als je alsnog oracle wilt gebruiken kan je hier een 200MHz servertje voor geinstalleerd me Netware & Oracle komen ophalen . Licentievrij.

deadlock schreef op 19-01-2005 @ 13:14 :
Voor oude Oracle versies heb je een netware server nodig.

Hoe kom je daar bij? Oracle 8 draait bij mij gewoon hoor.

[Enlightenment]

deadlock schreef op 19-01-2005 @ 13:14 :
@Enlightenment: Ziet er puik uit. Wat voor manier om het secure te houden gebruik je?

Grootste punt van veiligheid is de parser. Je wilt veel functionaliteit bieden maar wel HTML veilig zijn etc. Dat laatste doe je door de post door een htmlentities() filter te smijten, die vrijwel alle speciale tekens omzet naar &xxx; dingen. Dus HTML verschijnt gewoon als tekst, de beste manier mijns inziens. Probleem is wel hoe je bijvoorbeeld smileys als <: ) nog kan toelaten, dat soort dingen. Als je voor deze filter dingen gaat omzetten naar HTML (zoals de smileys naar img tags omzetten), dan komt dat er dus als pure tekst uit. Dus als 1e moet je door een htmlentities() filter gooien en daarna alle tags omzetten. Dat zou dan betekenen dat je < > en een boel andere chars niet kan gebruiken, maar zijn truucjes om dat weer op te vangen.

En uiteraard is alles GPC safe, of magic_quotes_gpc nu aanstaat of uitstaat. Het script maakt verder gebruik van mod_rewrite die alles naar 1 script stuurt, dus rondnneuzen is er niet echt bij. Al met al best veilig denk ik.

De accounts zelf zijn sterk beveiligd. IP-locks en sessies met geavanceerde checks, dat zit wel goed.

Als je het hebt over dingen als flood protection; dat heb ik nog niet ingebouwd.

Trouwens, als je alsnog oracle wilt gebruiken kan je hier een 200MHz servertje voor geinstalleerd me Netware & Oracle komen ophalen . Licentievrij.

Oracle?

Gelezen wat ze met Peoplesoft hebben gedaan?

Enlightenment schreef op 19-01-2005 @ 13:09 :
Zal zelf nog wat benchmarken. Maar stel ik heb een grote tabbel met veel users, en een grote tabel met topics. Als ik dan een join doe, gaat dan dan niet f*cking traag? Bij een JOIN heb je sowieso een extra voorwaarde, WHERE `id` = `id`, om zo de twee tabellen te koppelen.

Euh, nee. Mits je de indexen goed hebt liggen natuurlijk.

select usr.name
from topic
join user as usr on usr.id = topic.usr_id_topcistart
where topic.id = 8

Voor optimale performance ligt hier een index op user.id, topic.id en topic.usr_id_topicstart.

Enlightenment schreef op 19-01-2005 @ 13:09 :

Mja maar dan is al vastgelegd wat elk bit doet. Flags zoals ik nu heb, zijn juist leuk omdat je later een nieuwe Z-flag erin kan proppen. Ook backwards-compatible enzo. Efficienter is misschien wel om als 2 bytes op te slaan ofzo. Dat zijn 16 bits, mwah.

Je kan met bits ook makkelijk nieuwe vlaggen toevoegen. Gewoon een bit ervoor zetten.

Bit3 = admin only

101 = admin, visible, closed

Enlightenment schreef op 19-01-2005 @ 13:09 :

Ik begon met het op papier zetten van de SQL tabellen, dat is goed gegaan en uiteindelijk aangemaakt en begonnen met de code. Verder heb ik veel kleine en minder kleine ideeen op papier gezet, en een beetje gebrainstormd.

En het functionele gedeelte? Staat dat ook op papier.

een vriend van mij gebruikt één product dat zijn hele omgeving beveiligt.
Hij hoeft zich behalve voor het parsen, nergens zorgen over te maken. Ben alleen de naam vergeten.

Edit: rotkat die op het toetsenbord springt en post.
en die ga ik hem natuurlijk afhandig maken. moet ergens op sourceforge staan

[Enlightenment]

Lief zijn voor poesje.

Maarja als je alles door een htmlentities() filter gooit, hoef je je ook geen zorgen te maken om parsen. Tenzij er een bug in PHP zou zitten, maar ik gebruik gewoon de laatste versie (PHP 5.0.2). Bovendien heb ik een vulnerability scanner op mn server.

[Enlightenment]

eddie schreef op 19-01-2005 @ 13:30 :
Euh, nee. Mits je de indexen goed hebt liggen natuurlijk.

select usr.name
from topic
join user as usr on usr.id = topic.usr_id_topcistart
where topic.id = 8

Voor optimale performance ligt hier een index op user.id, topic.id en topic.usr_id_topicstart.

Hm, ik deed het altijd zo:

SELECT *
FROM `users`,`groups`
WHERE `users`.`goup` = `groups`.`id`
AND `users`.`id` = 502;

Maar dat van jou is beter?

Je kan met bits ook makkelijk nieuwe vlaggen toevoegen. Gewoon een bit ervoor zetten.

Ja je hebt gelijk, zal ik aanpassen.

En het functionele gedeelte? Staat dat ook op papier.

Nee, maar hey ik doe inspiratie op tijdens het coden.

SQL moet je in het begin goed overna denken, maarja de rest kan ik altijd later nog aanpassen denk ik.

Wel een aantal keuzes die je maakt, parse ik de berichten per pageview of wanneer de user een post opstuurt. Ik heb voor het eerste gekozen. Stel het staat verkeerd in de db, dan nog is er geen gevaar. Daarnaast kom je dan niet aan de post, als de user die wilt editen zie je daar geen lelijke dingen door de parser gedaan. B.v. op dit forum zie je blabla@bla.com als je blabla@bla.com ingetypt hebt en daarna wilt editen. Lijkt me mooier om dat dus niet te doen. Maarja is wel weer intensiever misschien.

Performance is nog een groot punt.

Enlightenment schreef op 19-01-2005 @ 13:48 :
Hm, ik deed het altijd zo:

SELECT *
FROM `users`,`groups`
WHERE `users`.`goup` = `groups`.`id`
AND `users`.`id` = 502;

Maar dat van jou is beter?

Het is iig sneller.

In jou situatie wordt eerst alle records van de tabellen dmv een cross join bij elkaar gehaald (je krijgt dus een cartetisch (of hoe schrijf je dat) product). Elk record in tabel 1, wordt gelinkt aan alle records van tabel 2. Je tussentijdse resultaat is dus erg groot. Op dit tussentijdse resultaat wordt vervolgens je where toegepast.

Op de 'echte' manier, zoals ik liet zien, is je tussentijdse resultaat al een stuk kleiner, omdat je direct filtert op één (of meer) voorwaarde(s).

Enlightenment schreef op 19-01-2005 @ 13:48 :

Nee, maar hey ik doe inspiratie op tijdens het coden.

SQL moet je in het begin goed overna denken, maarja de rest kan ik altijd later nog aanpassen denk ik.

Toch kan het handig zijn om functionele dingen van tevoren (al dan niet simepl) uitwerken op papier, zodat je een goed overzicht hebt van wat je allemaal wilt gaan doen.

[Manuzhai]

Volgens mij maakt die JOIN-syntax niet uit, alleen is de expliciete JOIN waarschijnlijk beter ondersteund in databases anders dan MySQL (en DB independence zou natuurlijk op den duur best een mooie feature zijn).

Over React weet ik toevallig dat ze van een post zowel de ongeparste als de geparste versie van een bericht opslaan. Op die manier heb je het beste van beiden. Dit kost misschien iets meer schijfruimte, maar denk dat performance over het algemeen kostbaarder zal zijn dan schijfruimte.

In het algemeen geldt dat je zoveel mogelijk machinaties at post time wil doen, omdat de view actie veel vaker gebeurt dan de post actie.

Verder lijkt het extra opslaan van de username bij posts/topics me nog niet zo'n slecht idee. Volgens mij doet React dit ook. Het is niet moeilijk om bij een nickchange even door alle topics/posts heen te lopen en dat bij te werken, en gezien het feit dat nickchanges veel schaarser zouden moeten zijn dan het lezen van het forum is dat wederom een verstandige beslissing.

Schone code en een performance beter dan phpBB zijn in dit stadium nog niet zo moeilijk, natuurlijk. Dat wordt pas lastig te enforcen op het moment dat je veel meer features hebt.

(To set the record straight: Parse is het bedrijf, React het product, en GoT een implementatie ervan. Als je dus zegt dat het net zoveel features krijgt als GoT Parse praat je enorme onzin.)

Heb je al rekening gehouden met templating?

[Enlightenment]

Manuzhai schreef op 19-01-2005 @ 14:00 :
Over React weet ik toevallig dat ze van een post zowel de ongeparste als de geparste versie van een bericht opslaan. Op die manier heb je het beste van beiden. Dit kost misschien iets meer schijfruimte, maar denk dat performance over het algemeen kostbaarder zal zijn dan schijfruimte.

In het algemeen geldt dat je zoveel mogelijk machinaties at post time wil doen, omdat de view actie veel vaker gebeurt dan de post actie.

Poeh, da's wel bijna twee keer zo'n grote DB dan, want de posts zelf nemen de meeste plaats in. Wel handig, kun je bij het editen de edit-versie laten zien, en bij het viewen de reeds geparsede versie.

(To set the record straight: Parse is het bedrijf, React het product, en GoT een implementatie ervan. Als je dus zegt dat het net zoveel features krijgt als GoT Parse praat je enorme onzin.)

Gelijk gelijk.
React dan. Maar net zoveel features denk ik niet, React is enorm uitgebreid. Maar wel het soort handigheidjes dat ik op GoT zie.

Heb je al rekening gehouden met templating?

Nee.

Jouw manier zal een stuk meer toekomstbestendig zijn, op dit moment gebruik ik functies. Als een functie nog niet gedefinieerd is door config.php, dan gebruikt hij de default functie (die ik nu gebruik, daarom is alles engels).

Ik wil ook eerst het functioneel hebben, mocht ik later een mooi deftig templating systeem willen maken kan dat altijd nog. Lijkt me wel veel werk. :/

Enlightenment schreef op 19-01-2005 @ 13:02 :
Traag

Dat hangt helemaal van je perspectief af.

Als jij PHP code moet schrijven en meerdere SQL commando's moet uitvoeren in MySQL om iets te doen wat ik met een trigger in PostgreSQL kan doen, wat zal er dan sneller zijn denk je?

Scenario voor je keywords bij het wijzigen van een bericht:

PHP -> MySQL (update post) -> PHP -> MySQL (update keywords)

PHP -> PostgreSQL (update post, trigger regelt keywords automatisch)

Alleen omdat MySQL een redelijk goede SELECT performance heeft, is het niet per definitie een betere oplossing dan PostgreSQL.

[Manuzhai]

******** schreef op 19-01-2005 @ 14:09 :
Alleen omdat MySQL een redelijk goede SELECT performance heeft, is het niet per definitie een betere oplossing dan PostgreSQL.

Maar misschien wel per definitie van het internet-forum?

[Manuzhai]

Enlightenment schreef op 19-01-2005 @ 14:08 :
Ik wil ook eerst het functioneel hebben, mocht ik later een mooi deftig templating systeem willen maken kan dat altijd nog. Lijkt me wel veel werk. :/

Mijn manier is helemaal niet veel werk. Beperkt de mogelijke installatie alleen wel enigszins (als het ook op PHP 4 moet draaien, tenminste). Maar het is volgens mij toch al een forum dat expliciet gericht is op gebruikers die iets meer controle hebben over hun hosting omgeving.

[Enlightenment]

******** schreef op 19-01-2005 @ 14:09 :
Alleen omdat MySQL een redelijk goede SELECT performance heeft, is het niet per definitie een betere oplossing dan PostgreSQL.

Je hebt een punt. Toch denk ik dat als ik MySQL 4.0 vervang door de recentste production/stable PGSQL, mn site een stuk langzamer wordt (in benchmarks iig, mn server is nu snel zat en superrustig).

De benchmarks die ik heb gezien, waaronder vrij ingewikkelde SELECT en INSERT statements, geven een eenduidig beeld weer: MySQL is vele malen sneller. Als MySQL 5.x veel nieuwe functionaliteit toevoegt waar PGSQL het van moet hebben, is voor mij de keus ook vrij eenvoudig gemaakt.

[Enlightenment]

Manuzhai schreef op 19-01-2005 @ 14:12 :
Mijn manier is helemaal niet veel werk. Beperkt de mogelijke installatie alleen wel enigszins (als het ook op PHP 4 moet draaien, tenminste). Maar het is volgens mij toch al een forum dat expliciet gericht is op gebruikers die iets meer controle hebben over hun hosting omgeving.

Mja maar het is sowieso technologie waar ik me totaal niet in heb verdiept, dus in die zin is het wel veel werk.

Maar betekent niet dat ik het niet wil ofzo, maar ik kies liever voor een forum dat binnen een week aardig compleet is, dan dat ik een maand met een niet-functioneel forum zit.

Even overdreven gezegd.

[Manuzhai]

Je moet je code binnenkort maar in een Subversion repository gooien, dan kan ik zo templating erin bakken en dan kan je kijken hoe dat werkt.

(CVS is so 1995.)

Enlightenment schreef op 19-01-2005 @ 14:16 :

Maar betekent niet dat ik het niet wil ofzo, maar ik kies liever voor een forum dat binnen een week aardig compleet is, dan dat ik een maand met een niet-functioneel forum zit.

Oei. Dat is een foute aanpak.
Wanneer je vanaf het begin al rekening kunt houden met templates en security, is het makkelijker te programeren/onderhouden dan wanneer je alles achteraf moet inbouwen.

Template systemen zijn eenvoudig te maken, kan op deiverse manieren..

Als je een statisch uiterlijk hebt kun je een php bestand nemen en daar de complete layout inzetten + wat vars..
Als laatste include je deze template..

Een andere manier is gewoon plane text en daar bepaalde dingen zoals <!%variable%!> te replacen. Is wel iets trager.

Of je zet ieder onderdeel in een functie..
template_post($username,$etcetc) { }


Trouwens ook meerdere talen gebruiken..
Eenvoudig te doen door iedere taal een eigen bestand te laten gebruiken..

dutch.inc.php met:
$lan['key'] = "De vertaling";

english.inc.php met:
$lan['key'] = "The translation";

eddie schreef op 19-01-2005 @ 14:28 :
Oei. Dat is een foute aanpak.
Wanneer je vanaf het begin al rekening kunt houden met templates en security, is het makkelijker te programeren/onderhouden dan wanneer je alles achteraf moet inbouwen.

Dingen direct inbouwen kost ongeveer 20% van de tijd dan ze er later inbouwen..

[Manuzhai]

********** schreef op 19-01-2005 @ 14:41 :
Dingen direct inbouwen kost ongeveer 20% van de tijd dan ze er later inbouwen..

Behalve als je er direct rekening mee houdt dat je ze later gaat inbouwen.

Ik heb al eerder XSLT voorgesteld als templating system aan Enlightenment.

Manuzhai schreef op 19-01-2005 @ 14:45 :
Behalve als je er direct rekening mee houdt dat je ze later gaat inbouwen.

Ik heb al eerder XSLT voorgesteld als templating system aan Enlightenment.

Ja, grapjas


Maar een template systeem is iig heel belangrijk

[dafelix]

ikzelf ben ook bezig met een forum te maken, het is m'n eerste grote project in PHP

mijn forum is gekoppeld aan m'n site, accounts zijn daardoor op zowel site als forum te gebruiken.
In principe bestaat m'n hele site uit het forum, omdat een aantal sub-fora via de mainpage voor iedereen te bezichtigen zijn (denk aan, news posten in een forum, zichtbaar op de mainpage)

het enige waar ik op dit moment zit qua security, is het login gebeuren. Atm word via een form de gebruikersnaam+md5 encrypted password verstuurd (via JS), maar als iemand alleen de MD5 hash heeft, kan die ook gewoon inloggen.

mijn oplossing zou zijn koppelen aan een IP, maar dat geeft natuurlijk probs als iemand een proxy gebruikt.
Daarna dacht ik aan een systeem, die het wachtwoord+IP via MD5 codeert, dus iemand van een ander IP heeft niks aan de MD5-hash.

misschien iemand suggestie's idee-en over hoe en wat?

En om het toch ontopic te houden, hoe heb jij dat opgelost, Enlightenment?

http://forum.**********.nl

Dat is wat ik ooit gemaakt heb

********** schreef op 19-01-2005 @ 16:59 :
http://forum.**********.nl

Dat is wat ik ooit gemaakt heb

Opzich wel een leuke interface.

Het probleem met fora; Het moet echt iets anders bieden. Er zijn er een paar 100.
VBB is heel gaaf maar heel duur.
phpBB2 en YaBB zijn wel leuk maar missen vaak security en features. Ze zijn dan wel weer gratis en phpBB2 is niet al te langzaam.

deadlock schreef op 19-01-2005 @ 18:32 :
Opzich wel een leuke interface.

Het probleem met fora; Het moet echt iets anders bieden. Er zijn er een paar 100.
VBB is heel gaaf maar heel duur.
phpBB2 en YaBB zijn wel leuk maar missen vaak security en features. Ze zijn dan wel weer gratis en phpBB2 is niet al te langzaam.

vB is omgerekend 125 euro, dat vind ik zeker niet veel voor zo'n product.
Ligt natuurlijk maar net waar je het voor gebruikt, maar voor bijvoorbeeld hier is het zeker geen miskoop..
Het is vele malen beter dan phpBB..

Maar een eigen forum maken is leuker...

[Enlightenment]

dafelix schreef op 19-01-2005 @ 15:11 :
ikzelf ben ook bezig met een forum te maken, het is m'n eerste grote project in PHP

Ik heb eigenlijk al een groot project gehad, namelijk mijn CMS. Dat is bij elkaar zo'n ~450KB plaintext groot, wat ik zelf aardig wat vind. Dus exclusief de layout of site-specifieke onderdelen. Het forum dat ik wil maken, maak ik in eerste instantie als plugin voor mijn CMS, maar zal ook standalone moeten gaan werken.

misschien iemand suggestie's idee-en over hoe en wat?
En om het toch ontopic te houden, hoe heb jij dat opgelost, Enlightenment?

Ik maak gebruik van sessies. Elke sessie heeft een eigen Secure Session ID, of Session ID, afhankelijk of de gebruiker een IP lock gebruikt of niet. De sessiekey is niet afgeleid van het wachtwoord, en zal bij opnieuw inloggen weer veranderen naar een 32-byte phrase. De Secure Session ID is gekoppeld aan het IP en de user agent (de browserversie).

Het voordeel van sessies op deze manier, is dat deze niet je wachtwoord verklappen of maskeren. Als je de MD5 hebt van het wachtwoord kun je altijd inloggen gewoon, totdat het wachtwoord wordt veranderd. Bij sessies zal een sessie sowieso verlopen na x aantal dagen (ik heb de sessie ttd (time to die) ingesteld op 30-dagen). Daarnaast kan de gebruiker na het inloggen zien welke sessies er worden gebruikt en deze ook killen.

Al met al een van de veiligste server-side accountbeveiligingen denk ik, alleen cookies worden gebruikt verder geen client-side (javascript) shit.

Daarnaast ga ik in de toekomst bij het inloggen verschillende opties geven, zoals een optie "Publieke computer". Als je deze optie aanvinkt, zal je cookie met bijbehorende Session ID verwijderd worden zodra je de browser afsluit. Tevens is de timetodie op een dag ingesteld.

Al met al vrij veilig denk ik.

[Enlightenment]

********** schreef op 19-01-2005 @ 16:59 :
http://forum.**********.nl

Dat is wat ik ooit gemaakt heb

Ziet er erg mooi uit! Vind je het erg als ik dat 3d-effect van de tabellen van je jat?

Enlightenment schreef op 19-01-2005 @ 19:24 :
Ziet er erg mooi uit! Vind je het erg als ik dat 3d-effect van de tabellen van je jat?

Nee hoor..

(Krijg ik dan credits in een ver weggedrukt filetje? )

[Enlightenment]

********** schreef op 19-01-2005 @ 19:31 :
Nee hoor..

(Krijg ik dan credits in een ver weggedrukt filetje? )

font-size:10% ?

kga nu quotes enzo werkend maken

Ik heb lang, lang geleden (2001 volgens mij) ook eens aan een forum gewerkt.
Zonder van tevoren een ontwerp maken, onnodig ingewikkelde html (divs in divs in divs in divs; lekker css werd dat )

[Jordi]

Enlightenment schreef op 19-01-2005 @ 19:20 :
Ik maak gebruik van sessies. Elke sessie heeft een eigen Secure Session ID, of Session ID, afhankelijk of de gebruiker een IP lock gebruikt of niet. De sessiekey is niet afgeleid van het wachtwoord, en zal bij opnieuw inloggen weer veranderen naar een 32-byte phrase. De Secure Session ID is gekoppeld aan het IP en de user agent (de browserversie).

Het voordeel van sessies op deze manier, is dat deze niet je wachtwoord verklappen of maskeren. Als je de MD5 hebt van het wachtwoord kun je altijd inloggen gewoon, totdat het wachtwoord wordt veranderd. Bij sessies zal een sessie sowieso verlopen na x aantal dagen (ik heb de sessie ttd (time to die) ingesteld op 30-dagen).

Ik heb ook een forum gemaakt (of ja, eigenlijk is het nog niet helemaal af) en ik snap niet echt veel van al die securitydingen.
Als je bij mij inlogt, worden je gebruikersnaam en wachtwoord ongecodeerd naar de server gestuurd. Daar wordt het wachtwoord met md5 gecodeerd en vergeleken met het wachtwoord in de database (dat ook md5 is).
Dan kunnen mensen toch niet inloggen als ze alleen de md5-dinges hebben? Want als ze dat dan invoeren, wordt dat ook weer md5 gecodeerd en dan verandert het dus. Toch?
Verder snap ik ook niet zo goed waarom je je sessies moet beveiligen. Ik maak gewoon een sessie met de user_id, de username en het emailadres aan en die laatste twee eigenlijk ook alleen maar zodat ik ze niet steeds uit de db hoef te halen, het wachtwoord komt dus niet in een sessie. Alles werkt verder via $_SESSION[ 'user_id'], als die bestaat is iemand ingelogd en anders niet. Is dit echt zo onveilig? (en waarom?)

Enlightenment schreef op 19-01-2005 @ 13:27 :
Grootste punt van veiligheid is de parser. Je wilt veel functionaliteit bieden maar wel HTML veilig zijn etc. Dat laatste doe je door de post door een htmlentities() filter te smijten, die vrijwel alle speciale tekens omzet naar &xxx; dingen. Dus HTML verschijnt gewoon als tekst, de beste manier mijns inziens. Probleem is wel hoe je bijvoorbeeld smileys als <: ) nog kan toelaten, dat soort dingen. Als je voor deze filter dingen gaat omzetten naar HTML (zoals de smileys naar img tags omzetten), dan komt dat er dus als pure tekst uit. Dus als 1e moet je door een htmlentities() filter gooien en daarna alle tags omzetten. Dat zou dan betekenen dat je < > en een boel andere chars niet kan gebruiken, maar zijn truucjes om dat weer op te vangen.

Ehm, wat is parsen en wat is een parser?
Verder snap ik het probleem met die htmlentities() niet zo. Als je die functie gewoon gebruikt op het bericht dat je in de db gaat zetten en er dan rekening mee houdt in je regular expressions, dan werkt het toch gewoon? Misschien dat je nu gewoon een nieuwe post naar de database stuurt en dan pas htmlentities() gebruikt nadat je [img] hebt vervangen door <img ... >. Dan zal het inderdaad wel niet werken, maar als je zorgt dat die echte html-tags (van <img ... > ) pas worden neergezet nadat je htmlentities hebt gebruikt, dan moet het werken toch?

Enlightenment schreef op 19-01-2005 @ 13:27 :
En uiteraard is alles GPC safe, of magic_quotes_gpc nu aanstaat of uitstaat. Het script maakt verder gebruik van mod_rewrite die alles naar 1 script stuurt, dus rondnneuzen is er niet echt bij. Al met al best veilig denk ik.

Van dit stukje snap ik helemaal niets. Wat is GPC (safe), magic_quotes_gpc en mod_rewrite? En waarom zouden mensen rond kunnen neuzen?

Sorry voor de vele vragen...

[Enlightenment]

Jordi schreef op 20-01-2005 @ 12:48 :
Ik heb ook een forum gemaakt (of ja, eigenlijk is het nog niet helemaal af) en ik snap niet echt veel van al die securitydingen.
Als je bij mij inlogt, worden je gebruikersnaam en wachtwoord ongecodeerd naar de server gestuurd. Daar wordt het wachtwoord met md5 gecodeerd en vergeleken met het wachtwoord in de database (dat ook md5 is).

Ouch. Dus je hebt het wachtwoord ongecodeerd in cookie staan, en daarmee kan met ongelimiteerd inloggen no matter what? Tja dat is dus behoorlijk brak.

Maar als je forum een hobbyprojectje is en usersecurity geen prioriteit is, hoeft het geeneens zo erg te zijn.

Dan kunnen mensen toch niet inloggen als ze alleen de md5-dinges hebben? Want als ze dat dan invoeren, wordt dat ook weer md5 gecodeerd en dan verandert het dus. Toch?

MD5 maakt niet uit, als ze cookie jatten van iemand dan hebben ze het wachtwoord, daarmee kunnen ze inloggen, onbeperkt en overal.

Verder snap ik ook niet zo goed waarom je je sessies moet beveiligen. Ik maak gewoon een sessie met de user_id, de username en het emailadres aan en die laatste twee eigenlijk ook alleen maar zodat ik ze niet steeds uit de db hoef te halen, het wachtwoord komt dus niet in een sessie. Alles werkt verder via $_SESSION[ 'user_id'], als die bestaat is iemand ingelogd en anders niet. Is dit echt zo onveilig? (en waarom?)

Je moet twee dingen uit elkaar houden: PHP Sessies (PHPSESSID) en een eigen sessie-systeem. Ik doe het als volgt: bij het inloggen maak ik een secure session cookie aan, na 2 dagen komt de gebruiker terug op de site en bij de 1e pageview wordt hij automatisch ingelogd. Hij stuurt dan de secure session cookie op naar de server, de server controleert of deze geldig is. De server heeft de 32-byte tekenreeks onthouden en daaraan is een IP-adres en browserstring gekoppeld. Als alles in orde is (zelfde IP en browser), zal de gebruiker toegang krijgen tot de juiste access levels, deze worden opgeslagen in de PHP Sessie. Deze sessie wordt gekilled zodra de browser afgesloten wordt, en heeft een maximale duur van 1 dag. PHP sessie is dus de tijdelijke sessie en Secure Session (ssid) is de cookie van mn eigen systeem die een dag, een maand of een jaar geldig kan blijven. Mocht iemand toch onverhoopt toegang krijgen tot de ssid, dan heeft hij het wachtwoord niet van het account, hij zou misschien wel kunnen inloggen, maar door alle sessies te resetten (killen) is hij alle rechten kwijt en kan hij niks meer. Zeker een stuk veiliger dus.

Ehm, wat is parsen en wat is een parser?

Parsen betekent omzetten of interpreteren, in dit verband het omzetten van UBB tags zoals [ b] [ /b] naar HTML-code. Alle tags die je in een bericht kan gebruiken, net zoals [ /quote].

Verder snap ik het probleem met die htmlentities() niet zo. Als je die functie gewoon gebruikt op het bericht dat je in de db gaat zetten en er dan rekening mee houdt in je regular expressions, dan werkt het toch gewoon? Misschien dat je nu gewoon een nieuwe post naar de database stuurt en dan pas htmlentities() gebruikt nadat je [img] hebt vervangen door <img ... >. Dan zal het inderdaad wel niet werken, maar als je zorgt dat die echte html-tags (van <img ... > ) pas worden neergezet nadat je htmlentities hebt gebruikt, dan moet het werken toch?

Ja dat doe ik nu dus, maar smileys zoals < enzo veranderen ook. Valt allemaal wel op te vangen hoor, maar werken met regular expressions om weerbaar te zijn tegen foutieve-tags (niet goed afgesloten etc.) is niet mijn specialiteit.

Van dit stukje snap ik helemaal niets. Wat is GPC (safe), magic_quotes_gpc en mod_rewrite? En waarom zouden mensen rond kunnen neuzen?

GPC = Get Post Cookie, de drie superscope variabelen waarin informatie wordt opgeslagen die van de client komt. De client kan zelf bepalen wat hij stuurt in deze drie variabelen, en met de heilige regel "Do not trust user input" in ons achterhoofd moeten we dus heel voorzichtig zijn met deze drie variabelen. Als je GPC variabelen in een SQL statement gebruikt, is er het gevaar dat een client met een gefabriceerde string de statement kan onderbreken en dingen als DROP DB kan doen, hetgeen je niet wilt.

Om dat te voorkomen is het belangrijk dat GPC geen " of ' kan bevatten. Een functie zoals mysql_escape_string() plaats / slashes voor elke " of '. MySQL zal daardoor het teken erna als teken behandelen, en niet de string escapen. Hierdoor blijft alles wat van GPC afkomt als string en niet als data/instructies.

magic_quotes_gpc is een configuratie optie in php.ini die automatisch alle GPC-variabelen escaped, zodat je ze direct in SQL statements kunt gebruiken zonder mysql_escape_string() functie. Je kunt ze ook uitzetten als je zelf netjes met de code omgaat, zoals ik doe. Dat heeft wat andere voordelen.

mod_rewrite gebruik ik om ALLE requests naar 1 php file te sluizen. Mensen kunnen dus niet directories op de server rondneuzen en direct php scripts aanroepen. Dat vermindert de kans op hack-acties ook enigszins. Alles komt binnen op een centraal script die vervolgens de juiste scripts aanroept afhankelijk van de url. Daardoor krijg je ook mooie URLs, geen:

http://forum.fluffles.net/viewforum.php?f=7

Maar:

www.fluffles.net/forum/devschuur

en voor een topic:

www.fluffles.net/forum/devschuur/5

Staat een stuk professioneler vind ik.