Bene, memcached non ha alcuna configurazione dei permessi (solo i permessi del socket di ascolto). È sufficiente avviare il daemon e tutti gli oggetti di memoria che gli vengono inviati verranno memorizzati in base alla chiave. Non vi è alcuna distinzione tra l'utente o il computer che invia o recupera i dati, è anche possibile ottenere collisioni con le chiavi.
Memcached è stato progettato per essere semplice, costringendo il livello dell'applicazione a pensare a tutto il resto. E originariamente progettato per essere eseguito sulla stessa macchina dell'applicazione. Quel design non è cambiato dal 2013.
Tutto ciò detto, se un provider di hosting ti dà un socket su una macchina diversa a cui ti colleghi direttamente a memcached, allora dovresti smettere immediatamente di usare quel provider di hosting. Questo è semplicemente poco saggio. I provider di hosting che utilizzano memcached eseguiranno un daemon memcached diverso per ciascun utente (l'intero daemon è solo un paio di kilobyte), utilizzeranno un proxy inverso (con autenticazione) o costruiranno una cache compatibile memcached che non esegue realmente memcached.
Se guardi cosa fa AWS :
A Memcached layer is an AWS OpsWorks layer that provides a blueprint for instances that function as Memcached servers
vale a dire. la loro cache elastica può essere utilizzata come cache memcached, ma non è un daemon memcached in ascolto su un socket. E (dallo stesso articolo) puoi vedere che c'è un'autenticazione sulla tua cache:
Custom security groups
This setting appears if you chose to not automatically associate a
built-in AWS OpsWorks security group with your layers. You must
specify which security group to associate with the layer. For more
information, see Create a New Stack.
Pertanto, usare memcached come qualsiasi soluzione di rete, in particolare in un ambiente di hosting, è semplicemente poco saggio. Ma la maggior parte degli ambienti di hosting che pubblicizzano memcached, non usano realmente memcached, ma inseriscono un livello in da per aggiungere permessi.