What is the recommended way to store user settings in Parse Cloud?
I've two approaches of which I don't know which one is best suitable for a scalable app or if there is a better way of doing this.
The first approach is to create a class with all settings for each user and have a relation between the user and the setting.
The other approach is to simply store the settings for each user in a user object. I feel the second approach is the better one.
I've had a look at PFInstallation but not entirely sure if that can be used to set User Settings or if the use case is for push notifications only.
Both of your solutions:
an associated class to hold user settings
store attributes directly in the user class
Are valid.
The advantage of #1 is that it will be easier to secure the settings. In the case of #1, you can create an ACL when you create each user's setting object that will allow only the user associated with that record to read, edit or delete the settings object.
In the case of #2, if any of the fields are sensitive, then you'll need to explicitly protect those fields using the userSensitiveFields config key to ensure that they are not returned when user records are queried.
Related
I will have two or 3 types of users on the front (Clients, Providers, and Manufacturers) and each user will have different set of features and data profile.
Which is the best strategy you imagine for creating the content types for each type of user?
In my head, I have in mind to create 3 content types related to Users and set a field for USERTYPE, and the front requests the rest of the profile on the other content type.
What do you think?
Also related to security, is it possible to set access to contents according to different user types?
Thank you.
It's depending of you want to do and depending of your application need.
You can also create roles, one for Clients, one for Providers and one for Manufacturers. You will be able to manage who can do what.
For the accounts entity I have different account types.
However I need to make some of these records read only only based on the account type, as these records will be slaved in CRM.
However the user should still have ability to create other types of accounts that will be mastered in CRM.
I was thinking to do this via security role however when giving create or edit permission on the account entity user can still create accounts of any type or edit existing slaved data.
What would be the best way to make slaved data read only?
Use business rules to lock all fields based on the type?
Like you said, this cannot be achieved with security role, since the requirement is based on a field value.
Disabling all the form fields in bulk - You can do this in javascript quickly, or may be with Business rules one by one. Verify the field value on form load for your certain slaved value account type, then disable the controls by iterating each one of them.
Still subgrid, webresource, iframes will be editable.
What we are doing now is to modify(add/delete) ldap schema (OpenDJ) during runtime.
For example， our APP can DO below during runtime:
add a new attribute (ldap schema), say ns-gender. And add this new attribute into some person objectclass.
Thus, all users can have this attribute.
suppose we have existing 1000 user entries in OpenDJ, and all of these users has such an attribute.
And our App wants to delete this attribute during runtime as well. Which means, we have to:
a. iterate over all these existing 1000 users, delete the attribute from the user entry.
b. then delete the ns-gender schema
I'm wondering if there's an easier way to achieve this ?
Thanks
No there is no better or easier way.
Note that it is not a good practice to add and delete attributes definitions frequently with any LDAP directory service.
I'm new to using Parse.com and I'm trying to understand the general relationship between a logged in user and user-specific data.
I've figured out and understand how to create users and objects but I'm fuzzy on how to connect the two.
Is it as simple as creating a user and then once their logged in, storing an object with their username as the key?
Then when a user signs in successfully, you retrieve the object under their username key?
I just want to make sure I'm approaching this from the right angle, since I plan on having a lot of users and I also want the most secure approach.
I've read through the Parse.com documentation but can't seem to find the connection between the two. Any help is appreciated!
Do you mean when the user submits any details it is recorded with their User ID? If so, then this code will work for you:
ParseUser user = ParseUser.getCurrentUser();
//yourObjectID.put("User", user);
There is no user-specific data (all data is global with respect to the app ID you registered, as Parse is a database), but you can store data inside a ParseUser object. You can also give it access controls (an ACL), so only that user can read/write it. When the user signs in successfully, I don't believe it will be part of the ParseUser object yet, you need to fetch the data. (This is definitely true for object fields, but I'm not sure about simple fields like strings and ints. It deserves testing.)
There is a caveat to this. Depending on which SDK you're using, some of that information may be cached. In Unity 3D, for instance, the ParseUser object will retain all its data between program invocations (and indeed, will remain logged in).
I add new users.
Let's presume we add a field of 'additionaldata1' on the parse user class
I do NOT want the user to be able to see the data stored in 'additionaldata1' and as such don't want it returned when I query the current parse users.
Seeing as the code is a web.app I don't want it to be possible for a user to 'hack' the local code in order to bring back 'all' their user object data.
So my question is how do I ensure that certain fields such as 'additionaldata1' are NEVER returned on the parse.com user object? Do I have to set up an additional class that is related to the user but set the ACL as non-read? Or can I set ACL per field on the user class?
EDIT//
UPDATE: I believe I worked this out myself. It doesn't appear to be possible to set ACL per field on a class. As such I have to add this data into an additional class with a RELATION and then set the ACL on that class table to 'no read' and 'no write'. That way only cloud code can see the class values due to the master key and I can run any validation and queries via cloud code where I need that data to be secure / private from the user.
This case is mentioned in Parse Docs under one-to-one relational data https://www.parse.com/docs/relations_guide#onetoone_anchor.
They recommend that you split up the data into two tables and use a one-to-one:
In Parse, a one-to-one relationship is great for situations where you need to split one object into two objects. These situations should be rare, but two examples include:
Limiting visibility of some user data. In this scenario, you would split the object in two, where one portion of the object contains data that is visible to other users, while the related object contains data that is private to the original user (and protected via ACLs).
Splitting up an object for size. In this scenario, your original object is greater than the 128K maximum size permitted for an object, so you decide to create a secondary object to house extra data. It is usually better to design your data model to avoid objects this large, rather than splitting them up. If you can't avoid doing so, you can also consider storing large data in a Parse File.