Sessie systeem: DB of Native

  • Hoi,


    Zoals sommige weten werk ik momenteel aan mijn use case project. Nou had ik een vraag aangezien ik nogal twijfel over het controleren of een gebruiker is ingelogd. Ik wil hier sowieso werken met een sessie systeem alleen zit echt met een conflict aangezien ik hier geen keuze mee kan maken.


    Native: (standaard $_SESSION)
    Voordelen:
    - Makkelijk in gebruik omdat de gebruiker geen sessie gegevens kan aanpassen;
    - Makkelijk controleerbaar om de user id op te halen


    Nadelen:
    - Heeft extra variabelen nodig (ip, browser etc.) om sessie hijacking te voorkomen;
    - Sessie tijd loopt normaliter gezien af nadat de browser gesloten is


    Database:
    Voordelen:
    - In eigen beheer. Dus meer controle over de sessies;
    - Veiligere manier vind ik zelf dan


    Nadelen:
    - Sessie hijacking blijft mogelijk net zoals bij de native (zelfde principe om het op te lossen)
    - Extra laadtijd omdat hij extra queries moet uitvoeren (niet dat dit veel is maar toch)



    Het doel is dus dat je met meerdere ip adressen wel tegelijk kan inloggen, dit omdat ik zelf ook gebruik wil maken van het systeem en niet opnieuw wil inloggen op mijn PDA als ik naar de site ga
    ;)

  • Citaat van Db-maffia

    Ik zou kiezen voor de Native-way.. dit is wel iets meer werk om de beveiliging in te bouwen maar zo heb je ook geen onnodige info in je DB van alle users.


    Op zich heb je wel gelijk en ben blij dat je je mening wilt delen :) Maar goed ik ben een control freak, ik moet dus wel een overzicht hebben wat er gebeurd op mijn site en door wie.


    Even offtopic maar dit kan je misschien wel een beter inzicht geven wat er nog meer achter de schermen gaat gebeuren:
    Er komt een detectie systeem om 'scriptkiddies' aan te pakken. Tenminste mijn firewall systeem is bijna afgerond naar 4 maand. Dit in combinatie met mijn anti bot systeem (wat nog wel een struikelpuntje gaat hebben omdat ik hem moet integreren in Kohana 3.0). Ik moet hiermee dus ook nieuwe patronen kunnen opsporen hoe bots te werk gaan vandaar dat ik graag ook een login overzicht wil.


    Waarschijnlijk als je dit zo leest denk je misschien dat ik al een besluit heb genomen maar dit is nog niet zo, Misschien ga ik een andere manier verzinnen om patronen van echte gebruikers in kaart te zetten om mijn service te kunnen verbeteren qua veiligheid e.d.

  • MrMees
    Je bent mijn held van de dag. Gister was Darsstar het maar nu jij :p
    Ik had bij het registreren van een account ook een ip check. Maar als je met een bedrijf of op school onder hetzelfde adres een account wil maken krijg je een error xd. Dom van me.


    Db-maffia
    Nee ik heb voor elke user een apart .txt bestand in de map /userdata/{naam}.txt met een plain text wachtwoord :p


    Hierboven is een grap natuurlijk maarja ik zit wel meer te denken om het via de database te doen. Moet straks alleen nog een scriptje schrijven wat logs bijhoud van mensen die dingen willen doen die niet zijn toegestaan.


    Bedankt al in ieder geval. Meer reacties zijn welkom.

  • Het loggen is zeg maar dit:
    - Gebruiker gaat naar een plek waar hij/zij geen toegang toe heeft. Dit is een melding met als prioriteit 'laag'
    - Een gebruiker wil sql injecties of xss proberen om mijn site op te leuk. Dit is dan weer een melding met een hoge prioriteit.


    Het is nog wel wat ingewikkelder maar dat bespaar jullie wel :p

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!