Session id met/zonder cookie?

Ik begrijp nog niet goed waarom je het volgende zou doen, als een sessie het ook voor je kan doen..

- inloggen
- controle gegevens (eventueel met ook ip, en inlogpogingen, en inlogvertraging 2 seconden)
- cookie aanmaken met hash

Cookies zijn immers client-side en sessions server-side

Als men de cookies lokaal verwijderd, ben je weer terug bij het inloggen, wat je dus met sessions kan opvangen.

Dus terug naar je laatste vraag: "Wat zou hier dan nog het doel zijn van een session?"
Waarom cookies gebruiken als het ook met sessions kan?

Bedankt voor je reactie..
Misschien maak ik wel een denkfout bij gebrek aan kennis van PHP.
De site is in principe openbaar.
Maar reacties kunnen alleen door leden worden gegeven.
Gaat trouwens hoofdzakelijk dan om email die bekend moet zijn om reactie te versturen.
Documenten toevoegen, en flyers, youtubes, enz. daar moet wel voor ingelogd zijn.
Als ik met cookie werk, dan zijn de gegevens direct beschikbaar.
En hoeft men in principe niet in te loggen.
Of zie ik wat over het hoofd?

Mij ontgaat even het 1 en het ander.

1. waarom wil je geen database gebruiken?
2. Of je nou een database gebruikt of niet, wat jij wil bereiken is altijd mogelijk.

Geeft eens duidelijk aan wat je echt daadwerkelijk wilt bereiken want deze 2 teksten geven mij het idee dat je verkeerd bezig bent:

"Misschien maak ik wel een denkfout bij gebrek aan kennis van PHP."

"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."

Ik zet en verander gegevens in een mini foto (ongeveer 1kb) via IPTC. (per lid).
Dat werkt prima via PHP.
Dus is wel een soort database, maar niet volgens de 'normale' begrippen.
En de problemen en oplossingen blijven ook grotendeels hetzelfde.
Het is een site voor promotie van artiesten, die zelf de gegevens aanleveren.

Het inloggen zal niet zoveel problemen geven.
Inloggen is nodig voor aanleveren (en wijzigen) van documenten, flyers, enz.

Het bekijken van de site is openbaar.
Maar als er vragen gesteld worden, dan kunnen alleen leden daarop reageren.
Dat reageren gaat via email van het ene lid naar het andere lid.
Dus van het reagerende lid moet ik wat gegevens hebben (naam, email).
Die kan ik krijgen via inloggen, maar ook via een cookie.
Het is wat onpraktisch als lid gewoon wat bladert op de site.
En dan ergens reactie wil geven, en daarvoor moet inloggen.
Vandaar dat ik aan cookie denk.
Lijkt me wel veilig, wanneer steeds de inhoud van de cookie wordt gewijzigd.

Ikzelf heb ooit een inlogsysteem gemaakt met cookies, en die sloeg twee cookies op: Eentje met het userID, en eentje met een unieke hash.

Na het inloggen werden beiden in zowel de cookie als de database opgeslagen, en als ze overeenkwamen, dan waren ze ingelogd. Natuurlijk speelde er ook de mogelijkheid dat iemand een cookie zou stelen, maar dat heb ik toen tegengegaan met een IP-lock die een gebruiker bij het inloggen aan kon zetten waarmee de inlogsessie alleen als extra veiligheid op een bepaald IP geldig is.

Nu gebruik ik gewoon een PHP-session. En het is ook aan te raden om [php]session_regenerate_id[/php] te gebruiken tegen session hijacking of session fixation. Dit doe je dan direct na het inloggen. Op die manier is de eerder aangemaakte sessieID ongeldig en vervangen door een nieuwe. Dus als iemand van te voren je SessionID heeft gevonden, dan is die niet meer geldig zodra jij inlogt. Dit kan je natuurlijk ook uitvoeren op je gehele site.

Leuk leesvoer ervoer staat hier:
https://stackoverflow.com/questions/22965067/when-and-why-i-should-use-session-regenerate-id

Bedankt Arien.
Heb snel de link doorgelezen.
Maar ook daar is het wikken en wegen over gebruik van de sessions.
Of je geeft zowel een hacker als de klant de mogelijkeid om zich aan te melden.
Of je hebt de mogelijkheid om de klant buiten spel te zetten in bepaalde situaties.

Het is natuurlijk een promotiesite.
Dus veel gegevens zijn te lezen.
Meeste problemen zouden veroorzaakt kunnen worden door jatten van adres, email.
Dat adres is ook niet verplicht bij registratie.
Men heeft daarbij de keuze uit niets, postcode, volledig adres.
Wel makkelijk vanwege zoektocht in de embedded googlemaps.
De verschillende pagina's zijn ook al klaar.
Gaat nu vooral nog om het inloggen, en het vragen om de gegevens bij een reactie.
Dat inloggen lukt wel.
Maar ik twijfel nog over inloggen voor reactie geven.
Als dat automatisch kan met PHP, heel graag...
Zou mijn methode met cookie anders een groot veiligheidsprobleem kunnen opleveren?

Je zou de werking van session_regenerate_id natuurlijk kunnen nabootsen, om tijdens het bezoek in de admin een ander sessie-ID te gebruiken in de cookie en database. Dat voorkomt hijacking.

Het enige voordeel als enkel cookies gebruik is dat je controle de sessies hebt. Zo kan een gebruiker zijn inlogsessie die hij gemaakt heeft op zijn werk weer thuis uitloggen. Met normale sessies in PHP is deze na een kleine 30 minuten inactiviteit weer uitgelogd.

Dat gaat alleen maar op dan, als je de controle op IP zelf hebt, door aan of uit te zetten...
Ik heb nu de mogelijkheid dat leden na inloggen op andere locatie een mail ontvangen.
En via de mail worden verwezen naar pagina om dit extra ip-adres te kunnen toevoegen. (moet ik nog uitwerken)
Is ook nodig bij GSM als IPadres wijzigt of je gebruikt regelmatig meerdere locaties (GSM, PC, Ipad, Werk)
Ik denk nu toch in de richting van de cookie.