/u/199524/axva.png?f=community)
Ik ben bezig met een PHP/MySQL projectje waar users berichten en attachments kunnen ontvangen. Om die bestanden op te slaan ben ik van plan om gebruik te maken van Google Cloud Storage. Berichten kunnen dan bijv naast een "lijst met attachmentnamen" ook inline afbeeldingen bevatten, waarvan de content dus meteen zichtbaar is bij het zien van dit bericht.
In een attachments bucket zullen deze files worden opgeslagen, bijvoorbeeld met als pad /attachments/<user_id>/<message_id>/<db_file_id>/filename.ext. Geavanceerd ACL is ingeschakeld.
So far so good volgens mij. Het uploaden is niet zo spannend, de bestanden worden vervolgens als niet openbaar ingesteld.
Nu twijfel ik alleen over de beste aanpak om de bestanden weer op te halen. Ik heb volgens mij deze mogelijkheden:
1. Publieke bestanden gebruiken met random filenames, zodat die URL meteen bij elke file in de database wordt opgeslagen, waardoor er geen enkele latency/overhead is.
2. In feite een PHP proxy gebruiken waarbij een view.php?id=XX de niet-publieke content vanuit GCS uitleest, en vervolgens output naar de user. In view.php kan ik controleren of de user de juiste rechten heeft en de user heeft geen idee dat het bestand in GCS staat.
3a. View.php?id=XX haalt voor elke attachment een signed URL bij GCS op, en redirect de user naar deze URL. De user heeft dan de volledige URL, iedereen met deze URL kan het bestand opvragen.
3b. Ook een signed URL, maar dan met een limit van bijv. 15 minuten. Dan is de URL 'publiekelijk' max. 15 min te benaderen.
Optie 1 lijkt me eigenlijk wel meteen af te vallen, immers een hoog potentieel veiligheids-/privacyrisico.
Optie 2 klinkt op het eerste gezicht wel een goede optie maar daar lijkt het me dat je met dubbele bandwith zit en meer latency overhead hebt? Immers moet het bestand eerst van GCS worden gedownload, en dan geserveerd worden aan de user.
Optie 3 geeft minder mooie URL's - signed URL's zijn nu eenmaal vrij lang en 'lelijk'. Daarbij zit je ook nog met (enige?) overhead. Want bij inline images moet direct een signed URL worden opgehaald. Wanneer je dit niet met AJAX zou doen, en er 10 afbeeldingen in één bericht staan, heb je 10 x ~100ms(?) latency voordat het script verder kan worden uitgevoerd?
De lijst met (niet inline) attachments kunnen nog steeds doorlinken naar View.php?id=xx. Daardoor heb je daar slechts 1 x ~100ms latency.
Bij 3a zou dit probleem maar één keer optreden omdat de signed URL onbeperkt houdbaar is, daar da's bijna hetzelfde als optie 1. Bij 3b zou je bij elke page refresh bij wijze van spreken hetzelfde proces moeten doorlopen.
Wat zouden jullie doen, zijn er andere best practices hiervoor? Hoop dat ik het een beetje duidelijk heb omschreven
In een attachments bucket zullen deze files worden opgeslagen, bijvoorbeeld met als pad /attachments/<user_id>/<message_id>/<db_file_id>/filename.ext. Geavanceerd ACL is ingeschakeld.
So far so good volgens mij. Het uploaden is niet zo spannend, de bestanden worden vervolgens als niet openbaar ingesteld.
Nu twijfel ik alleen over de beste aanpak om de bestanden weer op te halen. Ik heb volgens mij deze mogelijkheden:
1. Publieke bestanden gebruiken met random filenames, zodat die URL meteen bij elke file in de database wordt opgeslagen, waardoor er geen enkele latency/overhead is.
2. In feite een PHP proxy gebruiken waarbij een view.php?id=XX de niet-publieke content vanuit GCS uitleest, en vervolgens output naar de user. In view.php kan ik controleren of de user de juiste rechten heeft en de user heeft geen idee dat het bestand in GCS staat.
3a. View.php?id=XX haalt voor elke attachment een signed URL bij GCS op, en redirect de user naar deze URL. De user heeft dan de volledige URL, iedereen met deze URL kan het bestand opvragen.
3b. Ook een signed URL, maar dan met een limit van bijv. 15 minuten. Dan is de URL 'publiekelijk' max. 15 min te benaderen.
Optie 1 lijkt me eigenlijk wel meteen af te vallen, immers een hoog potentieel veiligheids-/privacyrisico.
Optie 2 klinkt op het eerste gezicht wel een goede optie maar daar lijkt het me dat je met dubbele bandwith zit en meer latency overhead hebt? Immers moet het bestand eerst van GCS worden gedownload, en dan geserveerd worden aan de user.
Optie 3 geeft minder mooie URL's - signed URL's zijn nu eenmaal vrij lang en 'lelijk'. Daarbij zit je ook nog met (enige?) overhead. Want bij inline images moet direct een signed URL worden opgehaald. Wanneer je dit niet met AJAX zou doen, en er 10 afbeeldingen in één bericht staan, heb je 10 x ~100ms(?) latency voordat het script verder kan worden uitgevoerd?
De lijst met (niet inline) attachments kunnen nog steeds doorlinken naar View.php?id=xx. Daardoor heb je daar slechts 1 x ~100ms latency.
Bij 3a zou dit probleem maar één keer optreden omdat de signed URL onbeperkt houdbaar is, daar da's bijna hetzelfde als optie 1. Bij 3b zou je bij elke page refresh bij wijze van spreken hetzelfde proces moeten doorlopen.
Wat zouden jullie doen, zijn er andere best practices hiervoor? Hoop dat ik het een beetje duidelijk heb omschreven
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
/u/3106/crop601874b34ff83_cropped.png?f=community)
Zo doen grote namen zoals Zendesk en Slack het ook niet volgens mij. Enig idee hoe zij dit aanpakken?