Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

Aparte session voor beheerder naast andere inlogsessie?

Pagina: 1
Acties:

Verwijderd

Topicstarter
In een zelfgemaakt CMS'je check ik of iemand mag inloggen door te kijken of zijn combinatie username en wachtwoord in de database voorkomt. Zo ja, dan maak ik daar een sessie van:
$_SESSION['user_id'] = $row['user_id'];
In deze sessie zit dus het unieke ID van de betreffende user.

In hetzelfde record staat ook nog vermeld of deze persoon beheerder is (ja/nee). Omdat ik niet elke keer een query wil doen of de betreffende ingelogde user misschien ook een beheerder is, heb ik meteen ook de volgende sessie aangemaakt:
$_SESSION['user_beheerder'] = $row['beheerder'];
In deze sessie zit dus alleen of de user een beheerder is JA of NEE.

Aan de hand van of iemand die is ingelogd een beheerder is, laat ik wat meer opties zien in het menu en laat ik hem meer in de database stoppen. Ik vroeg me af of dit een juiste manier is. Het werkt wel lekker makkelijk, voor zover ik kan zien. Of zie ik nu misschien toch wat (qua veiligheid) over het hoofd hiermee?

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50

BikkelZ

CMD+Z

Ik denk dat je je beter eerst over https en SQL injection zorgen kunt maken rondom dit soort dingen. Zijn je queries clean? Gebruik je PDO? Loggen mensen in over https? De session is wel licht gekoppeld aan de cookies van de gebruiker* maar in feite als een aanvaller al zoveel controle heeft over de PC van een gebruiker dan stopt nog maar weinig ze.

* als je de sessie ook opslaat zodat als iemand terug komt hij weer ingelogd is

[ Voor 10% gewijzigd door BikkelZ op 06-05-2014 18:49 ]

iOS developer


Verwijderd

Topicstarter
Ja, ik kan PDO gebruiken. Https, eerst nog niet, misschien later wel. SQL injection vang ik (als het goed is) op elke query af. Er wordt over nagedacht in elk geval. :)

Maar ik begrijp uit het aanhalen van deze andere zaken dat de gebruikte manier met de 2 sessies op zich wel okee is? ;)

[ Voor 28% gewijzigd door Verwijderd op 06-05-2014 19:16 ]


Verwijderd

De sessiegegevens staan op de server, dus de enige die eraan kan komen is de serverapplicatie, als de server tenminste goed geconfigureerd en beveiligd is. Laten we daar even vanuit gaan. Ja, er is dan geen enkel probleem om een query te besparen door alvast die data in de sessiegegevens te laten staan.

Maar let wel, sessiebeheer wordt er minder mooi door. Door juist wel elke request even de gegevens uit de database te halen maak je het mogelijk voor de beheerder(s) en anderen om andere sessies uit te loggen. Dat is vaak erg prettig. Hoe duur is de query helemaal? Die hoort razend efficient te zijn.

  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50

BikkelZ

CMD+Z

Verwijderd schreef op dinsdag 06 mei 2014 @ 19:13:
Ja, ik kan PDO gebruiken. Https, eerst nog niet, misschien later wel. SQL injection vang ik (als het goed is) op elke query af. Er wordt over nagedacht in elk geval. :)

Maar ik begrijp uit het aanhalen van deze andere zaken dat de gebruikte manier met de 2 sessies op zich wel okee is? ;)
Ik snap dat je denkt dat je het handmatig al goed voor elkaar hebt maar je moet gewoon altijd meteen beginnen met PDO dat is een goede gewoonte. Maar inderdaad $_SESSION is redelijk veilig als je het netjes gebruikt en niet te dynamisch zoals $_SESSION($_GET["lulzvar"]).

Geen https gebruiken betekent dat een password unencrypted over bijvoorbeeld WiFi heen gaat. Even snoopen en je krijgt het verkeer gewoon binnen. Afvangen op interessante termen als password. Als je gezien hebt hoe makkelijk het werkt laat je niks belangrijks meer over http gaan.

iOS developer


Verwijderd

Topicstarter
Aha, dat is goed om te weten, Cheatah en BikkelZ.

Ik heb in mijn CMS ook bepaalde rubrieken, elk met een eigen ID, en daaronder hangen dan weer wat pagina's om dingen die daaronder hangen aan te passen. Nu geef ik dan in elke query ook dat ID van die rubriek mee (meegegeven via POST of de URL), omdat dat nodig is. Maar dat ID zou ik eigenlijk dan ook nog in een sessie kunnen stoppen, een sessie 'rubriek'. En zodra er een andere rubriek wordt geopend wordt de vorige sessie 'rubriek' overschreven met het nieuwe rubriek ID. Maar door wat Cheatah in zijn 2e alinea zegt ga ik dat maar niet doen denk ik. Aan de andere kant geef ik die rubriek ID elke keer in de URL mee of in een POST en dat is elke keer weer een variabele doorpasen. Misschien ook niet erg handig maar een andere optie heb ik eigenlijk niet, toch?

[ Voor 5% gewijzigd door Verwijderd op 06-05-2014 23:57 ]


  • BikkelZ
  • Registratie: Januari 2000
  • Laatst online: 21-02 08:50

BikkelZ

CMD+Z

Het internet is een verzameling van documenten die te vinden zijn via hyperlinks en daarmee ook weer naar elkaar kunnen linken. Waar je dus voor moet zorgen is dat alle data te vinden is onder een URL en dat die het liefste ook uniek is (ivm Google penalty voor duplicate content).

Het makkelijkst is om een MVC achtig framework te gebruiken en dan GET-routes te maken voor al je data. Je kunt ook $_GET query string parameters gebruiken of simpelweg unieke documenten maken, maar POST en SESSION zijn dus geen goede manieren om data op je site bereikbaar te maken want als je daar naar linkt krijg je dus niet weer het zelfde te zien omdat de sessie verlopen is of er geen data meegepost wordt.

iOS developer


Verwijderd

Topicstarter
Ha, je bent nog laat op! ;)

Aha okee. Maar ik gebruik alleen POST als er een formulier verzonden moet worden met nieuwe of aangepaste data. Het rubriek_id geef ik dan hidden mee. Let wel, dit is de backend, je moet dus eerst ingelogd zijn. Een formulier hier zal wel altijd met netjes alle data meegepost worden, tenzij een ingelogd persoon gaat zitten klooien door bijvoorbeeld vanaf een andere computer een formulier te gaan posten. Maar dat zal in mijn geval wel meevallen en als een nodige variabele niet binnenkomt, dan stuur ik de pagina toch gelijk terug vanaf de actiepagina. Enne, effe voor de zekerheid, ik wil juist niet dat hier geindexeerd wordt door bijv. Google (dus in mijn CMS pagina's staat overal noindex en nofollow in de top van de pagina). :)

En om biivoorbeeld bij zo'n formulier te komen gebruik ik een hyperlink met daarin bijvoorbeeld zoiets: foto-aanpassen.php?onderdeel=2&slideshow=3 die ik dan op de volgende pagina weer ophaal met $_REQUEST. Ik vroeg me dan af om de onderdeel in een sessie te gooien omdat er nog een een zooitje pagina's aan hangt en ik naast het elke keer in de URL erbij moet zetten, ik het ook aan het einde van de actiepagina weer mee moet geven naar de 'basis startpagina' met bijvoorbeeld header( "Location: welkom.php?onderdeel=2"). Als het in een sessie zou zitten zou dat niet hoeven. Maar dan wordt het misschien wel erg ingewikkeld en het middel erger dan de kwaal. ;)

Ik vroeg het me alleen opeens af en ik dacht 'laat ik het eens in de groep gooien'. Altijd leerzaam dit soort dingen, voor mij dan...

[ Voor 8% gewijzigd door Verwijderd op 07-05-2014 02:17 ]

Pagina: 1