(1) Iedereen vind het makkelijk als hij/zij niet hoeft in te loggen als je een site bezoekt waarvan je lid bent.
(2) Maar niemand vind het leuk als iemand anders op zijn/haar account gaat lopen prutsen.

Je wilt je bezoekers dus graag helpen met 1, maar 2 is minstens net zo belangrijk.
Vertel ons eens wat JIJ zou doen?
Een streng beleid is niet zozeer slecht, maar jaagt ook een deel van de doelgroep weg :(
Dat zou jammer zijn niet?
Jelmer schreef op 04.01.2006 17:47
Ik heb al eens gedacht aan zoiets, zie hier mijn ontwerp :)

@Sebastiaan: laten we PHPFreakz eens even gaan terroriseren >:)


En jij denkt dat dan nog kan?
Mitch schreef op 04.01.2006 17:53
Een streng beleid is niet zozeer slecht, maar jaagt ook een deel van de doelgroep weg :(
Dat zou jammer zijn niet?
Hun idee is goed: Spampoints
Hun beleid niet: Je krijgt veel te snel spampoints
Hoe ze ermee omgaan ook niet: Bij iedere spampoint vertraagt de site x seconden. (dat hoeft hier niet :-D)

Toch wordt het wel tijd dat die spampoints ook hier ingevoerd gaan worden vind ik...
Goh, ben ik toch nog op een criminals-site beland.
PHPhulp tegen PHPFreakz.......
Hun idee is goed: Spampoints
Hun beleid niet: Je krijgt veel te snel spampoints
Hoe ze ermee omgaan ook niet: Bij iedere spampoint vertraagt de site x seconden. (dat hoeft hier niet :-D)

Toch wordt het wel tijd dat die spampoints ook hier ingevoerd gaan worden vind ik...[/quote]

Dan krijg jij je eerste 50? En wat schiet je er dan mee op 'spam points'.
Steffan schreef op 04.01.2006 18:11
En wat schiet je er dan mee op 'spam points'.


Als je er 500 hebt mag je gratis een kwartiertje spammen zoveel je wilt.
Mag dat echt? Dan geef ik de admin's hier heel veel werk.
Dan krijg jij je eerste 50?
Hoe dat zo? Ik ben hier niet degene met de meeste dubbelposts.

En wat schiet je er dan mee op 'spam points'?
Bestraffing voor dubbelposts en spammen (van script, tuts, etc)
ff denken over het probleem...

of je nou een code in de cookie zet en de daadwerkelijke info in de db, het geeft nog alle toegang, want dan heb je enkel de code nodig. Welk is dat een eerste stap want dan kun je de lifetime niet veranderen :).

Je wilt niet dat het zo is dat als de gebruiker z'n browser sluit en weer opent dat hij dan weer is uitgelogd, dan valt het idee weg...

Je kan wel aan een IP vast binden, maar dan zijn de dynamische gebruikers het slachtoffer :/.

Ik zou zeggen zorg dat de code in het cookie vaak genoeg vervangen wordt, zodat er geen tijd is voor misbruik? =S
Legolas schreef op 04.01.2006 18:52
ff denken over het probleem...

of je nou een code in de cookie zet en de daadwerkelijke info in de db, het geeft nog alle toegang, want dan heb je enkel de code nodig. Welk is dat een eerste stap want dan kun je de lifetime niet veranderen :).

Je wilt niet dat het zo is dat als de gebruiker z'n browser sluit en weer opent dat hij dan weer is uitgelogd, dan valt het idee weg...

Je kan wel aan een IP vast binden, maar dan zijn de dynamische gebruikers het slachtoffer :/.

Ik zou zeggen zorg dat de code in het cookie vaak genoeg vervangen wordt, zodat er geen tijd is voor misbruik? =S

Het grote probleem met cookies is dat ze onderschept kunnen worden en op een slecht beveiligde pc via internet uitgelezen kunnen worden. Wanneer een ander over het cookie beschikt, kan hij dus inloggen. Welliswaar een beperkte tijd, maar het kan. De koppeling met het ip-adres is, volgens mij, de enige manier om met enige zekerheid te kunnen stellen dat de gebruiker ook de eigenaar van het cookie is. Alle andere manieren zijn per definitie onveilig omdat alle benodige gegevens in het cookie staan. Iedereen die over dit cookie beschikt, kan zo inloggen.

Al blijft de vraag welke veiligheidsrisico's je loopt en wat de financieele schade is. Overigens is ook reputatieschade in geld uit te drukken.

Reageren