Met session ID zoeken of combinatie gebruikersnaam, email, enz.

Was dit dit ding waarbij je informatie opsloeg in de metadata van afbeeldingen? Ik ben nog steeds van mening dat dit niet de juiste plek is voor dit soort informatieopslag. Je stipt hier ook zelf een gemis aan: je kunt niet (snel) zoeken in data omdat de data niet gestructureerd is.

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.

Als je metadata wilt ophalen, dan sla ik die altijd op in de database, zodra ik de foto upload.
Met [php]exif_read_data[/php] kan je vaak een hoop interessante gegevens ophalen.

Bedankt voor je snelle reactie Thomas.
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]
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');

Ik zou de user-data opslaan in de database in de tabel users. Deze tabel heeft een autoincrement primary key die je user_id noemt. Iedere gebruiker heeft dus een uniek id.

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.

Bedankt Frank en Arien.
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.

Hier een manier om inlog gegevens gecodeerd over een http verbinding te sturen :

http://adoptive.esy.es/js-encrypt-decrypt/

Serieus?

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.

@Adoptive Solution: maar ... hoe krijg je dan die random waarde veilig aan de overkant?

Als je de vraag goed gelezen hebt gaat het erom welke al niet niet gecodeerde gegevens je gebruikt als referentie.
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.

Dit zijn heel dure operaties:

<?php
$files = glob(realpath($_SERVER[ 'DOCUMENT_ROOT' ]) . "../*.{jpg}", GLOB_BRACE);
foreach ($files as $file) {
    $i = new iptc(file);
    $r = $i->get(EMAIL);
    if ($r == $email) {
        // etc. ...
    }
}
?>

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.