DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Hoi,
ik zoek een script om clientdata te registreren. Zaken als OS, browser, versie etc.
Uiteindelijk ook een script/functie om schermresolutie etc. te analyseren.
Weet iemand waar ik zulke scripts kan vinden? Google geeft resultaat, maar ik ben niet geheel tevreden. Weet iemand een goede oplossing?
ik zoek een script om clientdata te registreren. Zaken als OS, browser, versie etc.
Uiteindelijk ook een script/functie om schermresolutie etc. te analyseren.
Weet iemand waar ik zulke scripts kan vinden? Google geeft resultaat, maar ik ben niet geheel tevreden. Weet iemand een goede oplossing?
Wat wil je onder andere weten van je bezoekers?
getallheaders() is verder een hele simpele oplossing: http://nl2.php.net/manual/nl/function.getallheaders.php . Daarmee kun je vrijwel alle nuttige informatie van je bezoekers ophalen.
getallheaders() is verder een hele simpele oplossing: http://nl2.php.net/manual/nl/function.getallheaders.php . Daarmee kun je vrijwel alle nuttige informatie van je bezoekers ophalen.
Hiermee kan ik de gegevens opvragen. Dank daarvoor, wist niet dat zoiets bestond.quote:Op zondag 27 mei 2007 22:40 schreef Tuvai.net het volgende:
Wat wil je onder andere weten van je bezoekers?
getallheaders() is verder een hele simpele oplossing: http://nl2.php.net/manual/nl/function.getallheaders.php . Daarmee kun je vrijwel alle nuttige informatie van je bezoekers ophalen.
Nu wil ik ook nog een script dat de gegevens transformeert naar "begrijpelijke" waarden
brows = firefox
version = 2.0.3
Country = The Netherlands
Language = dutch
OS = Linux
OS-version = suse
Op dit niveau. De headers opvragen is niet moeilijk, maar deze interpreteren is een tweede. Niet moeilijk, maar veel werk. En er zijn scripts die dit kunnen, die vind ik via Google. Maar wat is goed en wat niet?
OS, OS-versie, browser, browser-versie en met wat geluk taal zijn uit je headers te halen. Country kan je met een ip2location database vinden en word met wat geluk ook in je $_SERVER gezet in dat geval hoef je geen ip2location database te gebruiken. Resoluties, kleuren, java, flash en javascript word wat lastiger maar dat kan je met javascript laten doen en dan een plaatje laten laden of een AJAX call in de achtergrond laten doen om de gegevens naar de server terug te sturen.quote:Op zondag 27 mei 2007 23:04 schreef beerten het volgende:
[..]
Hiermee kan ik de gegevens opvragen. Dank daarvoor, wist niet dat zoiets bestond.
Nu wil ik ook nog een script dat de gegevens transformeert naar "begrijpelijke" waarden
brows = firefox
version = 2.0.3
Country = The Netherlands
Language = dutch
OS = Linux
OS-version = suse
Op dit niveau. De headers opvragen is niet moeilijk, maar deze interpreteren is een tweede. Niet moeilijk, maar veel werk. En er zijn scripts die dit kunnen, die vind ik via Google. Maar wat is goed en wat niet?
Voor het header parsen staan op deze sites wel wat scripts er voor: http://www.phpclasses.org/
phluphy for president!
Die komen in feite allemaal op hetzelfde (getallheaders) neer. Zoals WyrilHaximus al zei kun je desnoods nog een Javascriptje runnen die ook nog dingen als resolutie-instellingen opzoekt, die staan immers niet tussen de getallheader() informatie-stukjes. Ik zou er geen groot script voor gaan downloaden, zelf iets dergelijks in elkaar zetten is écht niet veel werk; voornamelijk met foreach() door getallheaders() loopen.quote:Op zondag 27 mei 2007 23:04 schreef beerten het volgende:
[..]
Hiermee kan ik de gegevens opvragen. Dank daarvoor, wist niet dat zoiets bestond.
Nu wil ik ook nog een script dat de gegevens transformeert naar "begrijpelijke" waarden
brows = firefox
version = 2.0.3
Country = The Netherlands
Language = dutch
OS = Linux
OS-version = suse
Op dit niveau. De headers opvragen is niet moeilijk, maar deze interpreteren is een tweede. Niet moeilijk, maar veel werk. En er zijn scripts die dit kunnen, die vind ik via Google. Maar wat is goed en wat niet?
Zoals WyrilHaximus al zei kun je desnoods nog een Javascriptje runnen die ook nog dingen als resolutie-instellingen opzoekt, die staan immers niet tussen de getallheader() informatie-stukjes. Ik zou er geen groot script voor gaan downloaden, zelf iets dergelijks in elkaar zetten is écht niet veel werk; voornamelijk met foreach() door getallheaders() loopen. 
In navolging van bovenstaande vragen:
wat is de beste manier om bezoekers-data op te slaan? Een record per hit is best leuk, maar je zit binnen no-time met 100.000+ records in je tabel, en dan begint stats genereren zolang te duren heb ik gemerkt
Oplossing: data samenvoegen tot iets nuttings en uit je tabel gooien. Maar hoe?
Wat is slim / handig? Hoe hou je meeste / nuttigste informatie over?
wat is de beste manier om bezoekers-data op te slaan? Een record per hit is best leuk, maar je zit binnen no-time met 100.000+ records in je tabel, en dan begint stats genereren zolang te duren heb ik gemerkt
Oplossing: data samenvoegen tot iets nuttings en uit je tabel gooien. Maar hoe?
Wat is slim / handig? Hoe hou je meeste / nuttigste informatie over?
X: Zelf loop ik nu ook tegen dat probleem aan. (Alleen dan met 1.2M+ hits.) Wat je het beste kunt doen per dag of per week stats opslaan, en deze dan gegevens dan gebruiken om je overall stats te genereren. It's will be smart to save it as day, week, month, quarter year and year so you don't have to much load to make your overall stats. Something else that is smart to do it saving each bit of information that can be reused in a seperate table so you don't have the problem of huge amount of data in your index table. The reason for this is with growing tables they become slower to search and save data into.
phluphy for president!
quote:Op maandag 28 mei 2007 14:28 schreef WyriHaximus het volgende:
...
Normalisatie van je database dus.
Op het moment dat een gebruiker de site bezoekt, begint deze een sessie. --> tabel sessie
- sessie -id
- ip-adres
- profiel_id
Die gebruiker bezoekt pagina's, die behoren tot een sessie --> tabel
- visit-id
- sessie-id
- pagina-id
- timestamp
Pagina's worden door verschillende gebruikers opgevraagd ---> tabel
- pagina-id
- pagina-naam
Iedere gebruiker heeft een eigen profiel met zaken als OS, browser etc. Dit alles komt meerdere keren voor, dus een tabel 'profiel' met de data in subtabellen
-profiel-i
- browser-id
- os-id
- version-id
- screebres-id
- browser-id
- browser-name
- os-id
- os-name
Zoiets. Nu heb je nergens dubbele data staan en heb je je informatie zo kompact mogelijk = snel opgeslagen.
Deze opzet gebruik ik voor een script dat het gedrag van de gebruiker gaat analyseren. Wie bezoekt welke pagina, hoe browsen gebruikers door de sie, welke links/paden.
Daarnaast houdt het ook algemene stats bij.
Overigens staat de database layout versimpelt weergegeven.
version-id
- version-name
Dit had ik ook al bedacht idd... data per dag optellen, en per 7 dagen weer als week optellen etc.quote:Op maandag 28 mei 2007 14:28 schreef WyriHaximus het volgende:
It's will be smart to save it as day, week, month, quarter year and year so you don't have to much load to make your overall stats.
De data splitsen over meer tabellen vind ik dat weer niet handig, maar dat is meer vanuit de gedachte dat je de stats als iets 'extra' bijhoudt bij een site. Daar 6 tabellen ofzo voor gebruiken vind ik dan weer vrij veel, in verhouding ... als je een dedicated statistieken rapportage ding bouwt is dat een ander verhaal natuurlijk
Overigens gebruik ik meestal gewoon een OneStat account, scheelt mij weer een hoop gedoe
Ik gebruik 10 tabellen voor me stats . Komt vooral om de snelheid te verhogen . Queries kosten op een gegeven moment een secconde en dat alleen maar om wat stats en dat ging me toch echt iets te ver . En dat waren nog niet eens de stats dat was puur het reccorden . Voor een kleine site boeit het niet echt aangezien je toch niet bar veel hits zou hebben. Maar na me actie met een zooitje PvP Item kosten screenshots op de wow forums was ik in een weekje 500k hits rijker en dan ga je toch echt wel kijken naar hoe je dingen sneller kan laten gaan .quote:Op maandag 28 mei 2007 18:53 schreef Xcalibur het volgende:
[..]
Dit had ik ook al bedacht idd... data per dag optellen, en per 7 dagen weer als week optellen etc.
De data splitsen over meer tabellen vind ik dat weer niet handig, maar dat is meer vanuit de gedachte dat je de stats als iets 'extra' bijhoudt bij een site. Daar 6 tabellen ofzo voor gebruiken vind ik dan weer vrij veel, in verhouding ... als je een dedicated statistieken rapportage ding bouwt is dat een ander verhaal natuurlijk
Overigens gebruik ik meestal gewoon een OneStat account, scheelt mij weer een hoop gedoe
. Komt vooral om de snelheid te verhogen 
. En dat waren nog niet eens de stats dat was puur het reccorden 
. Voor een kleine site boeit het niet echt aangezien je toch niet bar veel hits zou hebben. Maar na me actie met een zooitje PvP Item kosten screenshots op de wow forums was ik in een weekje 500k hits rijker en dan ga je toch echt wel kijken naar hoe je dingen sneller kan laten gaan Ik begin me nu in eens af te vragen waarom ik zomaar engels ging praten daar .
.
phluphy for president!
Ja, dat vind ik dus teveel van het goede.... waarom doe je het eigenlijk zelf, en niet met een OneStat oid?quote:Op maandag 28 mei 2007 19:08 schreef WyriHaximus het volgende:
Ik gebruik 10 tabellen voor me stats .
Ik dacht dat je een quote ergens vandaan had gehaaldquote:Op maandag 28 mei 2007 19:08 schreef WyriHaximus het volgende:Ik begin me nu in eens af te vragen waarom ik zomaar engels ging praten daar .
geeft niet joh, gebruik ik er ook gewoon nog steeds naastquote:Op maandag 28 mei 2007 19:36 schreef JortK het volgende:
Foute post sorry.
Zie opmerking hierboven . De reden dat ik het zelf doe is eingelijk gewoon voor de fun en omdat ik wil kijken of ik zoiets netjes kan bouwen .quote:Op maandag 28 mei 2007 19:44 schreef Xcalibur het volgende:
[..]
Ja, dat vind ik dus teveel van het goede.... waarom doe je het eigenlijk zelf, en niet met een OneStat oid?
Nee zat ook wow te spelen en dat daar ook in gesprek maar dan in het engelsquote:Op maandag 28 mei 2007 19:44 schreef Xcalibur het volgende:
[..]
Ik dacht dat je een quote ergens vandaan had gehaald
phluphy for president!
Het heeft nog veel meer voordelen. Je kan precies zien wat een user uitvreet. Je kan zelfs post en get variabelen afvangen (alle formfields, zoektermen, errormessages etc.)quote:
Je kan het integreren in een beveiligingssysteem.
Je hebt namelijk een duidelijk profiel van de gebruiker (ip, sessie-id, browser, os etc) Als er gedurende de sessie ook maar iets veranderd is de sessie gestolen, dus een hack-attempt.
Wat de grootte van de tabellen betreft: Je zou inderdaad een onderhoudsscript kunnen schrijven dat op gezette tijden de dagstatistieken wegschrijft naar weken/maanden/dagen/uren. Zoiets.
Ja, duidelijk... maar wat is dan de 'best practise' zeg maar?quote:Op maandag 28 mei 2007 20:22 schreef beerten het volgende:
Wat de grootte van de tabellen betreft: Je zou inderdaad een onderhoudsscript kunnen schrijven dat op gezette tijden de dagstatistieken wegschrijft naar weken/maanden/dagen/uren. Zoiets.
Die is afhankelijk van je eisen als je bijvoorbeeld na 3 maanden genoegen neemt met een samenvatting per dag/maand, dan moet je de statistieken dus 'compileren' en opslaan. Je kunt er ook voor kiezen om bijvoorbeeld na 365 dagen statistieken te verwijderen, dan moet je dus per statistiek een timestamp gaan bijhouden. Het ligt er dus aan wat jij wilquote:Op maandag 28 mei 2007 20:27 schreef Xcalibur het volgende:
[..]
Ja, duidelijk... maar wat is dan de 'best practise' zeg maar?
Haha ik heb maar 9 tabellen voor mijn statistieken site (http://stats.bruggema.nl)
1 voor de telling (bv plugins, os, kleuren)
1 voor de datum telling
1 ip's
2 voor zoekmachines/zoekwoorden
1 voor laatste gebruikers
1 voor de referers
That's it..
1 voor de telling (bv plugins, os, kleuren)
1 voor de datum telling
1 ip's
2 voor zoekmachines/zoekwoorden
1 voor laatste gebruikers
1 voor de referers
That's it..
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Dus basicly $_SESSION, $_SERVER, $_POST en $_GET bij elke opgevraagde pagina wegschrijven?quote:Op maandag 28 mei 2007 20:22 schreef beerten het volgende:
[..]
Het heeft nog veel meer voordelen. Je kan precies zien wat een user uitvreet. Je kan zelfs post en get variabelen afvangen (alle formfields, zoektermen, errormessages etc.)
Je kan het integreren in een beveiligingssysteem.
Je hebt namelijk een duidelijk profiel van de gebruiker (ip, sessie-id, browser, os etc) Als er gedurende de sessie ook maar iets veranderd is de sessie gestolen, dus een hack-attempt.
Qua performance lijkt het mij sneller als je Apache dergelijke data naar de HDD laat schrijven.
Nee, dat is nu ook weer niet de bedoeling Dat vreet inderdaad te veel. Je zou het wel kunnen gebruiken op bepaalde pagina's om errormessages te loggen. Denk aan formulieren. Hiermee kan je zien welke fouten de gebruiker maakt en zo je website optimaliseren.quote:Op maandag 28 mei 2007 20:47 schreef Geqxon het volgende:
[..]
Dus basicly $_SESSION, $_SERVER, $_POST en $_GET bij elke opgevraagde pagina wegschrijven?
Qua performance lijkt het mij sneller als je Apache dergelijke data naar de HDD laat schrijven.
Ik had me alleen nog maar bedacht hoe. Niet naar de gevolgen en de uitvoering gekeken. Zover was ik nog niet....
Dit vind ik wel een interessante insteekquote:Op maandag 28 mei 2007 21:20 schreef beerten het volgende:
Je zou het wel kunnen gebruiken op bepaalde pagina's om errormessages te loggen. Denk aan formulieren. Hiermee kan je zien welke fouten de gebruiker maakt en zo je website optimaliseren.
Denk dat ik maar eens iets ga bedenken om zulk soort dingen standaard bij te houden...
Wat ik persoonlijk zou doen is perdag gegevens die ik nodig heb om statestieken te genereren op te slaan. En dan eens per week de gegevens voor die week uit die van de 7 dagen in die week halen. En dan op die fiets verder . Zo kan je van alle dagen stats laten zien maar ook van alles over de gehelen reccord tijd. Dit is handig als je ook reports wilt hebben over een bepaalde tijd waarin je een bepaalde actie heb gehad.quote:Op maandag 28 mei 2007 20:43 schreef JeRa het volgende:
[..]
Die is afhankelijk van je eisen als je bijvoorbeeld na 3 maanden genoegen neemt met een samenvatting per dag/maand, dan moet je de statistieken dus 'compileren' en opslaan. Je kunt er ook voor kiezen om bijvoorbeeld na 365 dagen statistieken te verwijderen, dan moet je dus per statistiek een timestamp gaan bijhouden. Het ligt er dus aan wat jij wil
Anyway zolang je je URL opslaat heb je automatish ook je $_GET . Zelf sla ik ook referers op en een waarschuwing, wat tegenwoordig ook vaak word gedaan is referer spamming, komt er op neer dat ze een random hit op je site doen met de referer van de site die aandacht moet hebben volgens hun. Deze referer zie je dan vaak verschijnen in stats. Het is iets om op te latten als je je stats ook andere laat zien .
phluphy for president!
Daar heb ik sinds een week of zo ineens erg last van. Vervelend. Is al zeker de vierde keer dat ik maatregelen moet nemen op mijn portfolio`tje tegen spam, waar maar iets van 40 bezoekers per dag op komen of zo. Gastenboek en Prikbordje heb ik al tig keren de 'beveiliging' van moeten aanpassen omdat d'r elke keer maar getracht werd te spammen. Vaak ook nog nutteloze spam, aangezien ze met hun URLs niet door m'n spamwoordenfilter komen en alleen maar een berichtje als 'nice...' achterlaten.quote:Op maandag 28 mei 2007 23:16 schreef WyriHaximus het volgende:
[..]
Wat ik persoonlijk zou doen is perdag gegevens die ik nodig heb om statestieken te genereren op te slaan. En dan eens per week de gegevens voor die week uit die van de 7 dagen in die week halen. En dan op die fiets verder . Zo kan je van alle dagen stats laten zien maar ook van alles over de gehelen reccord tijd. Dit is handig als je ook reports wilt hebben over een bepaalde tijd waarin je een bepaalde actie heb gehad.
Anyway zolang je je URL opslaat heb je automatish ook je $_GET . Zelf sla ik ook referers op en een waarschuwing, wat tegenwoordig ook vaak word gedaan is referer spamming, komt er op neer dat ze een random hit op je site doen met de referer van de site die aandacht moet hebben volgens hun. Deze referer zie je dan vaak verschijnen in stats. Het is iets om op te latten als je je stats ook andere laat zien .
Of zet er een vakje neer die je comment noemt maar vermeld in de tekst dat hier alleen een 0 getyped moet worden oid...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Ja idd ben zelf geen fan van plaatjes als website bezoeker maar als webmaster werken ze toch verdomde goed. Het eerste wat ik zelf ga maken als ik tijd heb er voor is een set met dat soort simpele vragen om het toch moeilijk te maken voor bots en makkelijk voor bezoekers.quote:Op dinsdag 29 mei 2007 07:47 schreef Chandler het volgende:
Of zet er een vakje neer die je comment noemt maar vermeld in de tekst dat hier alleen een 0 getyped moet worden oid...
Wat voorbeeldjes:
Welke van deze 2 blokjes is groen?
De aarde is:
Ik ben een:
(Ok ik zie mensen nog wel Bot invullen ook bij die xD.)
Etcetera etcetera, het werkt een stuk beter dan plaatjes aangezien iedereen een hekel aan die dingen heeft, vooral omdat de helft onduidelijk is of niet netjes grote en kleine letters afhandeld en je ze vaak mis hebt .
phluphy for president!
ik heb dergelijke problemen op een phpBB board, de CAPTCHA check die daarbij zit is zo lek als een mandje, terwijl dezelfde check het in het gastenboek prima doet... ? Anyway, daar zit nu een check op waarbij je een woord moet overtypen, die werkt tot nu toe feilloos. Sinds 11 mei heb ik al ruim 400 bot-meldingen gehad
Ik heb in begin heel veel captcha's gebruikt, maar zelfs daar gaan ze op een gegeven moment omheen komen, hoe random je ze ook maakt.quote:Op dinsdag 29 mei 2007 00:40 schreef Geqxon het volgende:
Laat je gebruikers een code overtypen?
Valt nog best mee. Vergeet niet dat phpBB zeer vaak gebruikt word en zeer makkelijk op te zetten is en daardoor een zeer aantrekkelijk doel is om aan te vallen. De CAPTCHA is gewoon gekraakt en word nu misbruikt om forums vol me te spammen. De bots zijn dan ook voor phpBB geschreven (of een module voor een bot), dat je de zelfde CAPTCHA voor je gasten boek gebruikt en daar geen last van hebt komt waarschijnlijk doordat ze het verkeerde proberen of gewoon helemaal geen CAPTCHA check uitvoeren . (Heb zelf gemiddeld 700 pogingen per week om me gastenboek te spammen.) Voor vBulliten gaat het zelfde op btw. Hoge bomen vangen veel wind.quote:Op dinsdag 29 mei 2007 08:41 schreef Xcalibur het volgende:
ik heb dergelijke problemen op een phpBB board, de CAPTCHA check die daarbij zit is zo lek als een mandje, terwijl dezelfde check het in het gastenboek prima doet... ? Anyway, daar zit nu een check op waarbij je een woord moet overtypen, die werkt tot nu toe feilloos. Sinds 11 mei heb ik al ruim 400 bot-meldingen gehad
phluphy for president!
Vervolg op m'n posts van vorige week.
Heb Ubuntu succesvol geïnstalleerd op een server. Vind het er nog mooier uitzien en lekkerder draaien dan Windows tot nu toe. Ik heb net eens een simpel PHP bestandje met phpinfo() gemaakt met de text editor en deze geopend in Firefox, wat uiteraard niet werkte. PHP en MySQL zouden in Ubuntu moeten zitten van wat ik begrepen heb, waar vind ik deze dan?
Heb Ubuntu succesvol geïnstalleerd op een server. Vind het er nog mooier uitzien en lekkerder draaien dan Windows tot nu toe. Ik heb net eens een simpel PHP bestandje met phpinfo() gemaakt met de text editor en deze geopend in Firefox, wat uiteraard niet werkte. PHP en MySQL zouden in Ubuntu moeten zitten van wat ik begrepen heb, waar vind ik deze dan?
Je kunt kijken of ze uberhaupt geinstalleerd zijn om te beginnen . En probeer anders eens op php.ini te zoekenquote:Op dinsdag 29 mei 2007 14:29 schreef Tuvai.net het volgende:
Vervolg op m'n posts van vorige week.
Heb Ubuntu succesvol geïnstalleerd op een server. Vind het er nog mooier uitzien en lekkerder draaien dan Windows tot nu toe. Ik heb net eens een simpel PHP bestandje met phpinfo() gemaakt met de text editor en deze geopend in Firefox, wat uiteraard niet werkte. PHP en MySQL zouden in Ubuntu moeten zitten van wat ik begrepen heb, waar vind ik deze dan?
phluphy for president!
[Linux/Unix] [/Gurus/helpen/newbies]% ./deel 17quote:Op dinsdag 29 mei 2007 14:29 schreef Tuvai.net het volgende:
Vervolg op m'n posts van vorige week.
Heb Ubuntu succesvol geïnstalleerd op een server. Vind het er nog mooier uitzien en lekkerder draaien dan Windows tot nu toe. Ik heb net eens een simpel PHP bestandje met phpinfo() gemaakt met de text editor en deze geopend in Firefox, wat uiteraard niet werkte. PHP en MySQL zouden in Ubuntu moeten zitten van wat ik begrepen heb, waar vind ik deze dan?
je kan via de commandline:
| 1 2 3 | sudo apt-get install mysql-server sudo apt-get install php5-cgi php5-mysql php5-gd php5 |
doen.
[ Bericht 3% gewijzigd door Tiemie op 29-05-2007 15:04:49 ]
Kan PHP.ini inderdaad niet vinden. Ik dacht dat alles al compleet in Ubuntu zou zitten.
Hoe kan ik nu het beste de nieuwste versies van PHP en MySQL installeren? Via 'Applications' -> 'Add/Remove...' of handmatig downloaden via php.net en mysql.com?
Hoe kan ik nu het beste de nieuwste versies van PHP en MySQL installeren? Via 'Applications' -> 'Add/Remove...' of handmatig downloaden via php.net en mysql.com?
kan apache-common niet vinden.quote:Op dinsdag 29 mei 2007 14:37 schreef Tiemie het volgende:
[..]
[Linux/Unix] [/Gurus/helpen/newbies]% ./deel 17
je kan via de commandline:
[ code verwijderd ]
doen.
Zegt genoeg denk ik.
apache2 dan.quote:Op dinsdag 29 mei 2007 14:49 schreef Tuvai.net het volgende:
[..]
kan apache-common niet vinden.
Zegt genoeg denk ik.
apt-cache search apache2quote:Op dinsdag 29 mei 2007 15:08 schreef Tuvai.net het volgende:
'zelfde resultaat.
Dan doet 'ie helemaal niks.
Sowieso eerst eens proberen om internet aan de gang te krijgen. Ik heb het juiste IP adres, subnetmasker en gateway al ingesteld, maar krijg nog niet veel. Zodra ik dat aan de gang heb ga ik eens proberen php te downloaden en te installeren.
Sowieso eerst eens proberen om internet aan de gang te krijgen. Ik heb het juiste IP adres, subnetmasker en gateway al ingesteld, maar krijg nog niet veel. Zodra ik dat aan de gang heb ga ik eens proberen php te downloaden en te installeren.
Ik wil graag even een blik op de beveiligingen die ik ingebouwd heb in mijn applicatie, kijken of ik misschien wat dingen over het hoofd heb gezien
Om in te loggen moet men een username en wachtwoord invoeren.
Het wachtwoord wordt als MD5 hash opgeslagen.
Hierin zitten de volgende checks:
1) Wanneer de username leeg of verkeerd is, dan komt de gebruiker terug bij de inlogpagina, met een melding dat de gegevens onjuist zijn.
2) Wanneer het password leeg of verkeerd is, dan komt de gebruiker ook terug bij de inlogpagina.
Wanneer deze twee checks positief zijn, dan wordt er een cookie geplant met daarin de hash van het password.
Op iedere pagina in de admin wordt een check gedaan op de cookie:
1) Wanneer de cookie er niet is, dan komt de gebruiker terecht op de inlogpagina.
2) Komt de inhoud van de cookie niet overeen met het password van de gebruiker, dan wordt de gebruiker ook teruggestuurd naar de inlogpagina.
Overigens is de var voor de username voorzien van mysql_real_escape_string();
Wat denken jullie ervan, volgens mij is de basis behoorlijk compleet?
Om in te loggen moet men een username en wachtwoord invoeren.
Het wachtwoord wordt als MD5 hash opgeslagen.
Hierin zitten de volgende checks:
1) Wanneer de username leeg of verkeerd is, dan komt de gebruiker terug bij de inlogpagina, met een melding dat de gegevens onjuist zijn.
2) Wanneer het password leeg of verkeerd is, dan komt de gebruiker ook terug bij de inlogpagina.
Wanneer deze twee checks positief zijn, dan wordt er een cookie geplant met daarin de hash van het password.
Op iedere pagina in de admin wordt een check gedaan op de cookie:
1) Wanneer de cookie er niet is, dan komt de gebruiker terecht op de inlogpagina.
2) Komt de inhoud van de cookie niet overeen met het password van de gebruiker, dan wordt de gebruiker ook teruggestuurd naar de inlogpagina.
Overigens is de var voor de username voorzien van mysql_real_escape_string();
Wat denken jullie ervan, volgens mij is de basis behoorlijk compleet?
JortK: hoe belangrijk is beveiliging voor je?
Wat ik sowieso nooit zou doen is een hash van het wachtwoord in de cookies zetten. Die worden dan bij iedere pagina opnieuw verstuurd en als iemand die onderschept kan die direct de gehele applicatie in.
Wat ik eerder zou doen is het userid in de sessie opslaan en daarbij gelijk het ipadres, browser etc... Mocht iemand dan de sessie hijacken dan zie je meteen een ander ipadres en log je de gebruiker uit. Daarnaast kun je opgeven hoe lang een sessie actief mag blijven, dat zou ik niet te lang zetten.
Er zijn daarnaast nog veel meer beveiligingen mogelijk, maar dat hangt allemaal af van hoe belangrijk beveiliging voor jou is. Je zou bijvoorbeeld ook https kunnen gebruiken.
Wat ik sowieso nooit zou doen is een hash van het wachtwoord in de cookies zetten. Die worden dan bij iedere pagina opnieuw verstuurd en als iemand die onderschept kan die direct de gehele applicatie in.
Wat ik eerder zou doen is het userid in de sessie opslaan en daarbij gelijk het ipadres, browser etc... Mocht iemand dan de sessie hijacken dan zie je meteen een ander ipadres en log je de gebruiker uit. Daarnaast kun je opgeven hoe lang een sessie actief mag blijven, dat zou ik niet te lang zetten.
Er zijn daarnaast nog veel meer beveiligingen mogelijk, maar dat hangt allemaal af van hoe belangrijk beveiliging voor jou is. Je zou bijvoorbeeld ook https kunnen gebruiken.
Hope for the best, prepare for the worst.
Ik gebruik beveiliging eigenlijk puur voor mezelf dat mensen niet blog posts kunnen maken en dat soort dingenquote:Op dinsdag 29 mei 2007 17:28 schreef cyberstalker het volgende:
JortK: hoe belangrijk is beveiliging voor je?
Wat ik sowieso nooit zou doen is een hash van het wachtwoord in de cookies zetten. Die worden dan bij iedere pagina opnieuw verstuurd en als iemand die onderschept kan die direct de gehele applicatie in.
Wat ik eerder zou doen is het userid in de sessie opslaan en daarbij gelijk het ipadres, browser etc... Mocht iemand dan de sessie hijacken dan zie je meteen een ander ipadres en log je de gebruiker uit. Daarnaast kun je opgeven hoe lang een sessie actief mag blijven, dat zou ik niet te lang zetten.
Er zijn daarnaast nog veel meer beveiligingen mogelijk, maar dat hangt allemaal af van hoe belangrijk beveiliging voor jou is. Je zou bijvoorbeeld ook https kunnen gebruiken.
Maar ik zal eens naar je punten kijken
Een cookie wordt toch opgeslagen op de pc van de gebruiker? Dus als jij ergens inlogt, je browser afsluit en weggaat, en de volgende persoon gaat naar je site, dan bestaat de cookie nog steeds. En is die persoon ingelogd
Geldigheid van de cookie niet onbeperkt lang instellen (wat ik nog steeds heel veel mensen zie doen) en het wachtwoord dat in de cookie staat encrypten; MD5 of SHA of zo.quote:Op dinsdag 29 mei 2007 17:52 schreef Piles het volgende:
Een cookie wordt toch opgeslagen op de pc van de gebruiker? Dus als jij ergens inlogt, je browser afsluit en weggaat, en de volgende persoon gaat naar je site, dan bestaat de cookie nog steeds. En is die persoon ingelogd
Waarom zou je een wachtwoord (encrypted of niet) in een cookie op willen slaan?
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Waarom zou je uberhaupt cookie's gebruiken? Je hebt toch sessies???
(al zijn dat in principe ook cookies)
Niet alle gebruikers hebben cookies ingeschakeld.
(al zijn dat in principe ook cookies)
Niet alle gebruikers hebben cookies ingeschakeld.
Een sessie verloopt zodra je de browser sluit (ala), een cookie is voor een lange tijd geldig.quote:Op dinsdag 29 mei 2007 19:00 schreef beerten het volgende:
Waarom zou je uberhaupt cookie's gebruiken? Je hebt toch sessies???
(al zijn dat in principe ook cookies)
Niet alle gebruikers hebben cookies ingeschakeld.
Zodat je elke keer als de gebruiker terugkomt een username/password check uit kunt voeren, mocht zijn password ergens op een andere computer gewijzigd zijnquote:Op dinsdag 29 mei 2007 18:29 schreef SuperRembo het volgende:
Waarom zou je een wachtwoord (encrypted of niet) in een cookie op willen slaan?
