Come impedire a un utente di parse.com di visualizzare parti dei propri dati utente? alias imposta ACL per campo sulla classe User?

Question

Aggiungo nuovi utenti. Presumiamo aggiungiamo un campo di 'additionaldata1' sulla classe utente parse

Non voglio che l'utente sia in grado di vedere i dati memorizzati nella 'additionaldata1' e come tale non ne vogliono sapere restituito quando interrogo gli attuali utenti di analisi.

Visto che il codice è un web.app, non voglio che un utente possa 'hackerare' il codice locale per riportare 'tutti' i propri dati dell'oggetto utente.

Quindi la mia domanda è: come posso garantire che determinati campi come "additionaldata1" non vengano MAI restituiti sull'oggetto utente parse.com? Devo impostare una classe aggiuntiva correlata all'utente ma impostare l'ACL come non letto? O posso impostare ACL per campo sulla classe utente?

MODIFICA // AGGIORNAMENTO: Credo di averlo risolto da solo. Non sembra possibile impostare ACL per campo su una classe. Come tale, devo aggiungere questi dati in una classe aggiuntiva con RELATION e quindi impostare l'ACL su quella tabella di classe su "no read" e "no write". In questo modo solo il codice cloud può vedere i valori della classe dovuti alla chiave master e posso eseguire qualsiasi convalida e query tramite codice cloud in cui ho bisogno che i dati siano protetti/privati ​​dall'utente.

Answer 1

Questo caso è menzionato in Parse Docs con dati relazionali one-to-one https://www.parse.com/docs/relations_guide#onetoone_anchor.

Essi raccomandano che vi siete lasciati i dati in due tabelle e utilizzare un one-to-one:

In Parse, una relazione uno-a-uno è grande per le situazioni in cui è necessario dividere un oggetto in due oggetti. Queste situazioni dovrebbero essere rare, ma due esempi includono:

Limitazione della visibilità di alcuni dati utente. In questo scenario, dividere l'oggetto in due, in cui una parte dell'oggetto contiene dati visibili ad altri utenti, mentre l'oggetto correlato contiene dati privati ​​all'utente originale (e protetti tramite ACL).

Dividere un oggetto per la dimensione. In questo scenario, l'oggetto originale è maggiore della dimensione massima di 128 KB consentita per un oggetto, quindi si decide di creare un oggetto secondario per ospitare dati aggiuntivi. Di solito è meglio progettare il modello dati per evitare oggetti così grandi, piuttosto che dividerli. Se non puoi evitare di farlo, puoi anche considerare di archiviare grandi dati in un file di analisi.