+- LiveCloud Forums (https://forums.livecloud.io)
+-- Forum: General (https://forums.livecloud.io/forumdisplay.php?fid=1)
+--- Forum: Getting Started (https://forums.livecloud.io/forumdisplay.php?fid=4)
+--- Thread: Both Universal and User Accounts (/showthread.php?tid=452)
Both Universal and User Accounts - Pebah - 07-20-2020
In my "book" application I want to have:
1. A universal account--to handle text and other data all users will see
2. A user account--to handle the user's personal data (bookmarks, etc.)
How is this done? I see in the docs, "Accounts and Authorization," descriptions of both, but it seems to describe it as either universal or user; I need both simultaneously.
Thanks!
RE: Both Universal and User Accounts - efrain.c - 07-20-2020
Hi Pebah,
Have you considered solving this with your data model instead?
The universal account can be replaced by a table. You can have a "universal" table that will store the text and other data the users will see.
The user account can be managed by the cdbUsers table. You can added keys to the users table for the user's personal data, like a "bookmarks" key. After a user signs in, you can use function cdb_readUsersByEmail(pEmail) to get their user record and access their personal data from there.
- Efrain
RE: Both Universal and User Accounts - Pebah - 07-20-2020
(07-20-2020, 07:54 PM)efrain.c Wrote: Hi Pebah,
Have you considered solving this with your data model instead?
The universal account can be replaced by a table. You can have a "universal" table that will store the text and other data the users will see.
The user account can be managed by the cdbUsers table. You can added keys to the users table for the user's personal data, like a "bookmarks" key. After a user signs in, you can use function cdb_readUsersByEmail(pEmail) to get their user record and access their personal data from there.
- Efrain
I didn't give you enough info. The universal data would be updated very often, so it cannot be in a table that is part of a user's account--if that is what you are suggesting.
I guess that what I'm not understanding is how to manage these two streams of data (universal and user) at the same time. Can that be done? I'm a neophyte with databases, and relatively unexperienced with LiveCloud's authorization methods.
When a user turns a page in the book, he will see the page filled with data from the universal account, and some data from his own account. So, both accounts are in use--how is this done with LiveCloud?
RE: Both Universal and User Accounts - efrain.c - 07-20-2020
We do not recommend the method using two accounts. The only way to do this would be to use two projects for one app. You would have to hardcode your developer credentials in your code so you can use cdb_sdk() to switch between projects. This is a security vulnerability.
The desired behavior can be acheived by using separate tables in the same project. Let me explain.
A newly created project has 2 tables by default, the cdbBlobs table and the cdbUsers table. The cdbUsers table contains a record for every user of this project. In your case, it will have a record for every users of your book app.
Let's say we were to create a "universal" table in this project. When you export the toolkit to your app, the book app will be aware of all tables in this project, including the "universal" table and the cdbUsers table.
When a user signs in you can get their user record using function cdb_readUsersByEmail(pEmail) and store it locally so you can access their personal data whenever you want.
You mentioned the "universal" data would be updated often. You have a couple options for this: cdb_sync() with "local" reads or stricty "cloud" reads.
You can perform "cloud" reads on the "universal" table so your user always sees what's on the cloud. Using "cloud" reads will be the closest to realtime data but will be less performant. (This might be the best solution for you if you're ok with the performance of the "cloud" reads)
Or when a user signs in, you can use function cdb_sync(pRecordIDL, pTable, pSource, pAllowDeletes, pDetectCollisions) with "cloud" for pSource on the "universal" table. This will download the current data on the cloud so it can be accessed locally. Using sync with "local" reads will be more performant but there's a chance the user can see stale data if anything on the cloud changes after the sync is called. You can perform this sync as often as you like so your user doesn't see stale data but it will affect performance.
Your app will have both the universal data and the user data so you can use them both as desired when a page is flipped.
RE: Both Universal and User Accounts - JereMiami - 09-29-2020
(07-20-2020, 09:54 PM)efrain.cYWe do not recommend the method using two accounts. The only way to do this would be to use two projects for one app. You would have to hardcode your developer credentials in your code so you can use cdb_sdk() to switch between projects. This is a security vulnerability. Wrote: Is there any way to use cdb_sdk() to move between projects without the developer being logged in?
RE: Both Universal and User Accounts - efrain.c - 09-29-2020
Hi JereMiami,
No, a developer must be authed to move between projects using cdb_sdk(). cdb_sdk() can still be used if a user is authed but it has to be on the current project.
RE: Both Universal and User Accounts - JereMiami - 10-02-2020
(09-29-2020, 11:30 PM)efrain.c Wrote: Hi JereMiami,
No, a developer must be authed to move between projects using cdb_sdk(). cdb_sdk() can still be used if a user is authed but it has to be on the current project.
Thanks- Very helpful.
RE: Both Universal and User Accounts - mark_talluto - 10-07-2020
One additional thought when syncing is to sync specific records. You do not have to sync the entire table.
- This makes the transaction more performant
- You improve security by only syncing data relevant to that user's data in the cdb_users table.
You can store their cdbRecordID to their cdb_users table in a local table, so you do not have to query for that data on every run of your app.
Working with the data locally, as Efrain said, is the most performant method possible. Should your app crash, or the client lose internet access, their data is store locally. The next sync will pick up the changes and send them to the cloud when conditions allow.