On https://developer.apple.com/documentation/cloudkit/ckcontainer/1640408-sharedclouddatabase it states:
Data stored in the shared database does not count against the storage quota of the current user’s iCloud account.
However that is unclear as to who pays for content stored in the shared database. So who pays for content stored in the shared database?
A shared database is actually just a shared view into someone’s private database, so the cost would fall on the private database owner.
Related
I have a basic chat application in GO, where users can create group threads and exchange messages and images which are stored inside these threads. Each thread is associated with its own cloud storage bucket and additionally the URLs of the images in a bucket are saved in Postgres. Right now I've set the permissions so that only the users that belong to a certain thread can view the images stored in its corresponding bucket with the help of this article.
What I don't understand is if a user that doesn't belong to a certain thread (and doesn't have view permissions for that bucket) can he still view the images inside it if he has their URLs?
I have an iOS App. Would like to explore what is needed to be done to achieve the following:
1) The user taps on the map
2) US Census Tract info is requested from database
3) Later the user wants to purchase this tract info.
The US Census Tract info would be uploaded to Cloud Object Storage.
There are 70,000 Tracts grouped by US States = 50 + 1 (DC)
I could use SQL Query to select one Census Tract by its ID.
In the iOS App I can use Apple Login and get users' name and email.
The question is how to grant/revoke access to this info automatically
after in-app purchase?
The question is two-fold. Do I have to create 70,000 CSV files and grant them an access to? Or this can be achieved dynamically with SQL?
The second part is - how to automate this process?
Does IBM Cloud has this capability?
I would expect that you would use a single Service ID that would have access to the data sitting in COS, and that a user's access to the underlying data would be handled in your application logic. The Cloud IAM access policies are not intended for end-users as much as for internal development/operations teams to manage access to various cloud resources.
Depending on the format of the census data, SQL Query could be a great way to do it. You could use SQL query to create a new object with the subset of data the user has requested, and then create a presigned URL that will expire in a whatever timeframe is reasonable, allowing the file to be downloaded to the client device.
Is it possible for an App running on multiple devices to have their own individual Firestore database, which the user of the device can access with their own login?
No. You would typically have each user access their own collection or subcollection within the database, identified by their Firebase Authentication user id, then protect that collection with security rules.
No. You would make a database with a child for every user to keep all his data. This structure is pretty common In apps. You could also add the security features that only a user can access his own data to make sure it’s individual
I am storing images of one user(owner) in google cloud storage bucket. I wanted to grant read permission for this image to a group of users(contacts of owner).I am planning to use Access Control List for this purpose; e.g., Owner will have full permission to his bucket and the contacts will have read permission on the images. There are chances that owner will have a very huge number of contacts, say 1 million.
So,
will there be any performance issue, if ACL contains a huge number of users?
Will this be the right approach for access control? Or should I consider signed URL?
Regards,Remya
This approach is not going to work for you. There are some significant limitations and downsides to trying to serve content like this. First and foremost, there is a limit of 100 ACL entries on a given object. You could get around this by granting permission to a group for which every user was a member, but even so, it still means that viewing the images will require that every user be logged in to their Google account in addition to however they authenticate for your site.
The canonical way to accomplish this would be to keep all images private and owned by your site's own account. When a user loads a page, verify however you like that they have appropriate authorization to view the images, and if so, generate signed URLs for the images. This allows you to use any authorization scheme without limitation while serving images directly from GCS.
I am writing an ERM application using the Zend Framework in which user accounts are created under a main company account, enabling me to limit the number of user accounts for a company based on the license which the company paid for. Each company account has its own database (with identical structure to other companies) on my server to store data relevant to that company. The name of each companies database is stored in my "back end" database along with the rest of the companies account information and license key. The authentication system works as follows:
A new user (having never used the application before) lands on the index page and is greeted by a single text field for "Company Account Number"
After clicking "Submit", the next step in authentication is for username and password. When the user submits this form, all three pieces of information (account number, user name and password) are sent to my application's Authentication handler.
My "back end" database which stores company accounts is first queried to see if the account entered by the user exists. If it does, the company_db_name column is returned and a connection established then saved in the Zend_Registry. Otherwise, authentication has failed.
If the company account does exist, the database that was returned then has its users table queried for the specified username and password hash which either returns a successful instance of MyApp_Auth or false if the credentials were incorrect.
At first, I planned on storing user session data in the individual companies database, however I have run into the problem that there is no connection to this database when first landing on the application's index page. I have planned a workaround as follows:
Move my session storage table out of the customer's database to my "backend" database, which has a connection as soon as the application launches.
Add a "company account number" column to the table and index this column.
When a user lands on the application index page, the backend database can then be queried for the current user agent's sessionid. If it is found, then return all the necessary information i.e. the company database name to establish a connection, and the user's information to build a model with.
I have a couple questions regarding this approach:
Question 1 : Is there any risk in storing all session information for every user of my application in a single back-end database table? I am thinking in the multi-thousand user mindset.
Question 2 : I am concerned that a new user may visit the index page and by complete chance (understanding that this is a very low possibility, but still possible) have the same session_id as an existing session in the back-end database. Is this a valid concern, and if so, can it be mitigated?
Question 3 : Is there a better way, or would you recommend a different method to achieve my required functionality?
Thank you for your time!
To answer your 3 questions:
Answer 1. The is not risk as such for the storing session information of every user as long as you remove it on session expiration. The issue here is "scalability" what approach are you using? Is it scalable enough? What is the write/read speed? MySQL is 'structured' approach just like MSSQL. What processing time are you looking for? How much of information is stored? What is the architectural studies. Is it feasible enough for your client?
Answer 2. Ideally the session_id will not be the same so that should not be your concern.
Answer 3. You need NoSQL (Not Only SQL but, even more) approach. Read this
Looking at the MASSIVE-ness of your data, I strongly suggest you to go for HBASE (uses Hadoop, easy for multi cluster) or CouchDB or if you are Amazon fan dynamoDB.
Questions? :)
EDIT: Just realized you are using Zend Framework. In that case, you can also use MongoDB, and use Shanty Mongo library.