Met session ID zoeken of combinatie gebruikersnaam, email, enz.
Bij het zoeken naar gegevens van lid gebruik ik nu de voorhanden zijnde gegevens
als Username, Email, enz.
Ik zou natuurlijk ook de gegevens van de session kunnen gebruiken.
De vaste session code bevat een uniek gegeven van een lid.
Omdat die session is gecodeerd moet ik het eerst omzetten voor referentie.
Wat betreft scripting maakt dat niet veel uit.
Tenzij ik de vaste session waarde ongecodeerd erin zet (=lidnr).
Dan kan ik direct op fotonaam (=lidnr) zoeken voor alle gegevens.
Lijkt me niet zo veilig.
Hoe zoeken jullie de gegevens?
Hieronder een voorbeeldje:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
$files = glob(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../*.{jpg}", GLOB_BRACE);
foreach($files as $file) {
$i = new iptc(file);
$r = $i->get(EMAIL);
if ($r == $email)
{
$lid_nr = $i->get(LID_NR);
$name = $i->get(NAME);
$ip = $i->get(IP);
break;
}
}
foreach($files as $file) {
$i = new iptc(file);
$r = $i->get(EMAIL);
if ($r == $email)
{
$lid_nr = $i->get(LID_NR);
$name = $i->get(NAME);
$ip = $i->get(IP);
break;
}
}
Daarnaast zijn dit soort diskoperaties knetterduur, veel inefficiënter wordt dit niet.
Als je dan toch wars bent van gebruik van enige database, denk dan bijvoorbeeld eens na over het gebruik van XML- of JSON-bestanden. Maar dan zul je toch snel tot de conclusie komen dat je in feite hetzelfde aan het maken bent als de functionaliteit die standaard al beschikbaar is wanneer je een database gebruikt.
Wat was nogmaals de reden dat je dit niet doet? Was je aan het experimenteren met iptc? Het kan geen kwaad om af en toe eens een stapje terug te nemen en je af te vragen of je nog steeds alles (makkelijk) kunt verwezenlijken met de gekozen oplossing.
Met exif_read_data kan je vaak een hoop interessante gegevens ophalen.
De data is heel gestructureerd in IPTC hoor.
Heb er ook een class voor om in te voeren en te wijzigen.
Het werken is ook best te vergelijken met database.
Is gewoon op grond van vergelijking en referentie gegevens ophalen en plaatsen.
Gaat mij er in de vraag om, of je de referenties om te halen en te plaatsen
van een sessioncode haalt of van de beschikbare gegevens als email, username, etc.
Hier een voorbeeld van een definitie zoals ik het gebruik in de class.
Per code kunnen er komma gescheiden gegevens geplaatst worden, gewijzigd en toegevoegd.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
DEFINE('LID_HASH', '005');
DEFINE('LID_NR', '007');
DEFINE('ARBEID_A', '010');
DEFINE('ARBEID_B', '015');
DEFINE('PASSWORD_HASH', '020');
DEFINE('TOKEN', '022');
DEFINE('EMAIL', '025');
DEFINE('USER_NAME', '030');
DEFINE('BIRTH', '035');
DEFINE('NAME', '040');
DEFINE('WEBSITE', '045');
DEFINE('FACEBOOK', '047');
DEFINE('YOUTUBE', '050');
DEFINE('ADDRESS', '055');
DEFINE('LATLON', '060');
DEFINE('COUNTRY_CODE', '065');
DEFINE('POST_ALL', '070');
DEFINE('IP', '075');
DEFINE('IP_B', '080');
DEFINE('IP_B_HASH', '085');
DEFINE('NEWS_LETTER', '090');
DEFINE('SESSION_CODE', '095');
DEFINE('CODE', '100');
DEFINE('BLOCK', '101');
DEFINE('BLOCK_ALWAYS', '103');
DEFINE('LAST_LOGIN', '105');
DEFINE('COOKIE_CODE', '110');
DEFINE('COOKIE_LID_HASH', '115');
DEFINE('USERNAME_HASH', '116');
DEFINE('SEARCH', '120');
DEFINE('FOLLOW', '121');
DEFINE('LID_NR', '007');
DEFINE('ARBEID_A', '010');
DEFINE('ARBEID_B', '015');
DEFINE('PASSWORD_HASH', '020');
DEFINE('TOKEN', '022');
DEFINE('EMAIL', '025');
DEFINE('USER_NAME', '030');
DEFINE('BIRTH', '035');
DEFINE('NAME', '040');
DEFINE('WEBSITE', '045');
DEFINE('FACEBOOK', '047');
DEFINE('YOUTUBE', '050');
DEFINE('ADDRESS', '055');
DEFINE('LATLON', '060');
DEFINE('COUNTRY_CODE', '065');
DEFINE('POST_ALL', '070');
DEFINE('IP', '075');
DEFINE('IP_B', '080');
DEFINE('IP_B_HASH', '085');
DEFINE('NEWS_LETTER', '090');
DEFINE('SESSION_CODE', '095');
DEFINE('CODE', '100');
DEFINE('BLOCK', '101');
DEFINE('BLOCK_ALWAYS', '103');
DEFINE('LAST_LOGIN', '105');
DEFINE('COOKIE_CODE', '110');
DEFINE('COOKIE_LID_HASH', '115');
DEFINE('USERNAME_HASH', '116');
DEFINE('SEARCH', '120');
DEFINE('FOLLOW', '121');
Gewijzigd op 09/11/2017 17:52:45 door Hans De Ridder
De user_id sla je op in de sessie, ongecodeerd.
Verder zou ik alle andere gegevens gewoon aan de hand van het user_id (dat in de sessie staat) uit de database trekken. Dan weet je zeker dat je de laatste versie van de user gegevens hebt namelijk.
Alles wat in de sessie staat is in principe veilig. PHP en SESSIE is dezelfde computer/server. Alleen het inloggen* zelf is onveilig als dit over het http:// protocol gaat. Gebruik dus een beveiligde verbinding, https://. Een ander belangrijk ding is dat je de passwords codeert en dan opslaat in de user tabel. Doe dit met BCRYPT. Gebruik hiervoor de php functies password_hash() en password_verify(). Bij het inloggen vergelijk je HASHES en niet de passwords.
* Bij het inloggen wordt het password ongecodeerd over internet verstuurd, althans als je geen https verbinding gebruikt. Hetzelfde probleem ontstaat natuurlijk wanneer er andere privacygevoelige informatie verstuurd wordt.
Op grond van de aanbevelingen in het verleden
is er ook hier met IPTC grotendeels gewerkt zoals Frank aangeeft.
Het unieke leden-ID is de foto.
Welke ook in de foto gecodeerd is opgeslagen.
De unieke gecodeerde leden-ID vind je ook terug in de sessie id.
Deze waarden zijn ook opgeslagen.
Waar nodig worden deze waarden vergeleken met de session gegevens.
Met daarnaast een willekeurige variabele sessioncode.
Daarnaast is het wachtwoord ook gehasht opgeslagen.
En worden de gecodeerde waardes vergeleken.
Dezelfde sessioncodes zijn ook opgeslagen als cookies.
Dit voor gebruik in het openbare gedeelte, waar uitsluitend leden kunnen reageren.
Was vooral benieuwd waar jullie de referenties vandaan halen:
Van de sessioncodes of de gegevens als email, en usernames.
http://adoptive.esy.es/js-encrypt-decrypt/
Je hebt op je server foto's staan met in de meta data van de foto (met willekeurige namen) de logingegevens staan?
En als je 499 users hebt, dan open je 499 foto's bij het inloggen (in het ongunstigste geval) om te zoeken naar de gegevens? Aangezien je geen enkele referentie hebt welke file je moet hebben.
Doet me denken aan die films van Nicolas Cage. Wat was het ook weer? National treasure?
Maak er dan 1 foto van met heel veel info.
Of gebruik gewoon een database.
Maar ja. Uit jouw topics begrijp ik wel dat je het allemaal graag heel anders doet dan de rest van de wereld.
Als ik ongecodeerd een uniek lidnr gebruik in de session is dat allemaal niet nodig.
Ook niet als ik de foto de naam geef van de vaste gecodeerde session id.
Ik gebruik nu 2 sessioncodes.
1 met vaste waarde en 1 variabel.
Die vaste had ik ook gecodeerd.
Overigens worden de gegevens buiten de root opgeslagen.
Het hele systeem is trouwens weer eenvoudig terug te vertalen naar een database.
Bovendien werkt de 'hele wereld' niet zoveel met IPTC.
Omzetten van document naar JPG.
En veel programma's die daar weer mee te maken hebben, Imagix, gd bibliotheek, enz.
Dat is al een wereld op zich.
Programma's die gelukkig aanwezig zijn op de gedeelde server van mijn provider.
Je hebt gelijk als je zegt dat ik anders werk dan de hele wereld.
Ik heb ook niks met standaarden.
Ik gebruik meest voorbeelden van scipts die werken.
En bouw die dan om naar andere methode.
Gewoon als hobby. En meestal met doel wat ik mezelf opleg.
Hoef niks te doen in opdracht.
Ben bijna 66. En met vrijwilligerswerk in commisies en besturen
wel gemerkt dat het kijken naar oplossingen in andere branches
essentieel is voor succes. Want met de bekende standaard-oplossingen
is iedereen wel bekend.
Misschien komt het daar wel vandaan.
Overigens maak ik wel degelijk gebruik van de adviezen die me aangedragen worden.
Maar wil er soms wel een andere draai aan geven, haha.
Bedankt voor je reactie.
Gewijzigd op 10/11/2017 11:05:03 door Hans De Ridder
Code (php)
Je doorloopt één voor één alle JPEG-bestanden in een directory enkel en alleen om een piepkleine string op te halen. De rest van de wereld gebruikt daarvoor gewoon een oplossing die zo'n string direct leest. Bijvoorbeeld uit een kleine database. Of een XML- of JSON-tekstbestand.
Je hebt nu eigenzinnig je eigen fiets op vierkante wielen ontworpen terwijl de rest van de wereld vrolijk rondrijdt in auto's met ronde wielen.
Het werkt wel, maar het brengt je niet ver, is bijzonder oncomfortabel en ziet er niet uit.
Code (php)
1
$filename = md5(strtolower($email)) . 'jpg';
Twijfelde alleen vanwege de veiligheid.
Maar ik denk dat ik de vaste waarde van de session ga gebruiken.
Met als extra check de variabele waarde.
Overigens loopt de sessie uitsluitend bij inloggen voor wijzigingen, etc.
De rest van de site is openbaar.
Dat komt er dan ongeveer zo uit te zien voor het ophalen:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$lidnr_foto = $_SESSION['vast'].'.jpg';
$path = realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "/../".$lidnr_foto;
$i = new iptc($path);
$c = $i->get(SESSION_VAR);
$d = $i->get(SESSION_VAST);
if ($c != $_SESSION['var'] || $d != $_SESSION['vast')
{
return 'Gegevens kloppen niet';
break;
}
else
{
// ophalen overige gegevens
}
$path = realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "/../".$lidnr_foto;
$i = new iptc($path);
$c = $i->get(SESSION_VAR);
$d = $i->get(SESSION_VAST);
if ($c != $_SESSION['var'] || $d != $_SESSION['vast')
{
return 'Gegevens kloppen niet';
break;
}
else
{
// ophalen overige gegevens
}
Gewijzigd op 10/11/2017 12:35:28 door Hans De Ridder
Dat gemis komt hier tot uitdrukking:
Code (php)
(a) Je bepaalt zélf wat er in de sessie wordt opgeslagen. Je hoeft dus niet steeds te controleren of wat je zelf (!) in de sessie hebt opgeslagen nog overkomt met wat je zelf (!) in een plaatje hebt opgeslagen.
(b) Je slaat pas iets op in de sessie nádat je hebt gecontroleerd of het voldoende veilig is voor verdere consumptie van de sessie. Je gaat niet omgekeerd zomaar van alles opslaan in een sessie en daarna bij iedere consumptie controleren of wat er in de sessie zit wel oké is. Meestal althans.
(c) Sessies worden veilig opgeslagen op je eigen server op een locatie die niet extern toegankelijk is. Dáárvoor heb je dat gedoe met IPTC-data in JPEG-bestanden buiten de root allemaal niet nodig. Je gebruikt de JPEG's buiten de root nu deels voor functionaliteit waarin PHP-sessies en de bijbehorende sessiebestanden zelf al voorzien.
Ward van der Put op 10/11/2017 15:44:58:
(c) Sessies worden veilig opgeslagen op je eigen server op een locatie die niet extern toegankelijk is.
Aha, dat triggerde iets in mijn geheugen. Topicstarter geeft aan dat het een gedeelde server was. Zou niet de eerste keer zijn dat iedereen schrijft in dezelfde sessie-directory :p.
Je kunt dan nog kathedralen van oplossingen bouwen (of die nou juist zijn of niet nog even in het midden gelaten :p), als je serverconfiguratie niet klopt ben je nog steeds nat.
Wat dus nog veel belangrijker is, controleer even waar je sessies worden weggezet. Of wellicht nog beter, schrijf deze weg naar een lokale directory (die je zelf expliciet instelt) buiten de webroot.
Bovendien zal altijd de zwakste schakel in de ketting breken. Heb je prachtig geavanceerd inlog systeem maar een onveilige file upload (om maar iets te noemen) ga je ook nat.
Mijn hosting kan de sessions wel plaatsen in mijn eigen home directory buiten de root.
Dus kan ik dat doen. Bedankt, want had ik me niet gerealiseerd.
Moet ik dan de session values nog anders opvragen?
Gewijzigd op 13/11/2017 10:47:28 door Hans De Ridder
Dan hoef je de index.php weer niet te vervuilen met opties.
Maar nog wel een paar opmerkingen omdat ik die stukjes nog over heb.
Is het gebruikelijk om na bewerking in een blok steeds een nieuwe set_session() te doen?
Ik zou denken: bij het inloggen de set_session. en start de session, en die loopt een bepaalde tijd door.
En bij de session_start(): begint de tijd dan weer opnieuw te lopen vanaf de start?
Wat zijn de gevolgen als je session verloopt tijdens een bewerking?
Bedankt overigens voor jullie geduld en reacties...
Dus ik hop dat je binnen in je toegangscontrole ook controleert of je $_SESSION['UserID'] bestaat.
Verder raad ik ook aan om NA een inlogactie dit uit te voeren, of zelfs vaker.
session_regenerate_id().
Daarmee maak je een nieuwe SessieID aan, en zo voorkom je dat een oude SessieID nog geldig is, die in handen zou kunnen komen van hackers.
Gewijzigd op 13/11/2017 20:33:37 door - Ariën -