Ik ben bezig met experimentele site.
Dus veel gaat net wat anders dan normaal...
Ik werk ook niet met gewone database, maar sla gegevens anders op.
Nu wil ik graag wat advies over een session.
Veelal worden voor sessions een session id gebruikt en een cookie.
Ik heb die sesssions alleen nodig op alle pagina's voor het herkennen of iemand lid is.
Want alleen zo kan er op de diverse items gereageerd worden.
Dat kan vanuit de sessie id.
Bezoekers kunnen wel lezen maar niet reageren.
Nu achterhaal ik al het ipv4 of ipv6 adres.
Ik heb nogal wat gelezen over maatregelen tegen hackers wat betreft sessions
En de cookies en sessions id.
ik hoef alleen te kunnen beschikken over het lidmaatschapsnr .
Dat zou ik kunnen verwerken in de session id. (En tijdelijk opslaan).
En dan nog alleen op de pagina's waar wat te reageren valt.
Hoe veilig is dat als ik die session ter controle ook vergelijk met het ipadres of ander vast gegeven (username?)
Dus zonder cookie.
Session support in PHP consists of a way to preserve certain data across subsequent accesses.
A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.
[size=xsmall]Toevoeging op 13/08/2017 15:04:32:[/size]
IP is onbruikbaar omdat er scholen/bedrijven zijn die geheel achter 1 ip-nummer functioneren. Ook bij een mobieltje omdat daar het ip-adres nog al eens wijzigt.
oke, bedankt voor je reactie.
Dan toch maar zo veilig mogelijk een session id en cookie aaanmaken.
Als ik voor de session id het al dan niet versleutelde lidmaatschapsnummer gebruik, is dat dan veilig?
Of zitten daar ook nadelen aan?
IP is onbruikbaar omdat er scholen/bedrijven zijn die geheel achter 1 ip-nummer functioneren.
Dit lijkt mij geen probleem, omdat iedereen nog steeds moet inloggen neem ik aan? Het IP is enkel een extra controle om te kijken of een sessie wel van een (redelijk) betrouwbare gebruiker afkomstig is. Als je de school of het bedrijf niet echt kan vertrouwen (omdat anderen mogelijk netwerkverkeer afluisteren of dat je zelf laks bent met het gebruiken van (publieke?) machines omdat je bijvoorbeeld je browsercache niet opschoont na gebruik of dat dit niet automatisch gebeurt) wordt het een ander verhaal natuurlijk. Als je zorgt dat je website HTTPS gebruikt wordt afluisteren van netwerkverkeer nagenoeg onmogelijk.
Ook bij een mobieltje omdat daar het ip-adres nog al eens wijzigt.
Als dit een issue is moet je hier voorzieningen voor treffen uiteraard.
Als je daar dan een hash van maakt lijkt het mij wel veilig.
Nee want als iemand het sessie id op een of andere manier bemachtigt ben je nog steeds nat, aangenomen dat je geen andere voorzieningen treft. Sessie-data komt een gebruiker toch niet aan maar als een gebruiker toegang heeft tot het sessie-id dan heeft 'ie in principe de sleutel naar deze data. Het is dan zaak dat je additionele controles doet (zoals een IP-check) om de identiteit van een gebruiker vast te stellen verder te waarborgen. Als je allen op hetzelfde netwerk zit en je je buurman niet kunt vertrouwen is enkel een IP-check uiteraard niet genoeg.
Bedankt voor je inbreng Thomas.
Ik heb meerdere opties. Gaat mij vooral om gebruiksgemak.
In principe zal reageren gebeuren via een form (email naar email).
Bij een session kan ik het emailadres terugvinden van het reagerende lid.
Ik kan in de form wel vragen om gebruikersnaam en wachtwoord..
En dat checken.
Maar is niet zo gebruiksvriendelijk.
Dan is inloggen alleen noodzakelijk bij wijziging(en) in registratiegegegevens.
En het insturen van documenten en flyers.
Maar dat gaat via pagina's die los staan van de openbare pagina's.
Het enige wat je in principe hoeft te onthouden in een sessie is een user id, na een succesvolle login. De rest stop je in de database en vraag je elke page-access met een query op (inclusief controle op IP waarmee het meest recent is ingelogd, of een andere manier om te garanderen dat niemand de sessie heeft overgenomen).
De reden waarom je geen userdata bijhoudt in een sessie is omdat deze dan elke keer geupdate zou moeten worden als deze in de db verandert, of mogelijk is het dan moeilijker om mensen geforceerd uit te loggen als je ook privileges (die je dan niet makkelijk kunt intrekken) in de sessie opslaat. Dit soort informatie zou je gewoon elke page-access opnieuw moeten opvragen middels eerder genoemde user id. En hierbij voer je dus wat extra controles uit, je neemt niet klakkeloos aan dat iemand is wie die zegt te zijn enkel en alleen op grond van sessie id.
Toch nog een vraag, waar ik nu tegenaan loop.
Ik stel me zo het volgende voor:
- inloggen
- controle gegevens (eventueel met ook ip, en inlogpogingen, en inlogvertraging 2 seconden)
- cookie aanmaken met hash
- cookie waarde in database. (Bij mij alternatief)
Bij pagina's waar ik info moet hebben van lid:
- cookie vergelijken met database.
- info ophalen
- inhoud cookie wijzigen in database en bij lid.
- instellen tijd cookie bij inactiviteit.
Wat zou hier dan nog het doel zijn van een session?
