realm
Root vs. /~/ and UserID Retrieval
How does a user create a realm in the root vs their own ~/ directory? I've tried using the URL path sans the ~, without success. Does an admin have to create it first? If that is true, will this always be the case? I thought I had this working back in some of the early builds, but now they only place I can get a user to create a Realm in is in their own ~/ folder. I am developing an app that needs small group access to the same realm data, and would like to not have to put it in one of the user directories.
Even with using the ~/ location, I am unclear on how to do two things. How would a user get another user's "userID" (I'm assuming .identity) in order to create a SyncPermissionChange? And then assuming that is successful, what would be the best way for the newly granted user to dynamically connect to the owner user's ~/ realm file path, if there isn't a way to get the grantor's id?
I'm sure the answer(s) have something to do with Notifications, but I'm just not seeing it.
@TotemChris regular users can only create Realms in their directory: /~/. You can create Realms in the base directory, but you would have to do so with an adminToken: https://realm.io/docs/realm-object-server/#admin-based
We don't offer yet a way to look up User records on the server, though you could build this functionality with the Node.js SDK in the Professional Edition. Instead, I would recommend you create your own UserRealm that is shared among all users (with the adminToken) then add your own User object into it after a user registers. Assuming your user base is small groups like you mentioned, this works fine since it isn't expensive to sync this UserRealm to every device.
From a security perspective, this is not a good idea. And this app is a professional iPad app for clinicians to use in their clinics. It stores patient health data on the ROS. I would not want a copy of all user accounts (clinicians using app) proliferating to all users of this app, across all clinics that have nothing to do with one another.
What would your suggestion be to control clinician access to only their clinic's data (could be 1-10 clinicians or more, per clinic), without creating a whole separate authentication mechanism like the suggested above? I cannot stand up a realm server per clinic, as the logistics wouldn't work, and I'm not ok with syncing all users of my app to all endpoint devices.
I would not want a copy of all user accounts (clinicians using app) proliferating to all users of this app, across all clinics that have nothing to do with one another.
Each clinic could easily have its own user list in a Realm that only they have access to.
I cannot stand up a realm server per clinic, as the logistics wouldn't work
You can serve multiple Realms with individual permissions from the same server. So you should be able to let all clinics have their own private data while still running it all on one server.
Easier said than done, because this requires somebody to pre-create the realm with an admin account, manually add user accounts, and adjust permissions. I am trying to build a pro app that is driven by In-app purchase auto-renewing subscriptions, with no developer/admin intervention. The end-user should be able to set up their clinic's own realm, and add their own users to that realm. I'm not sure how to do that with the current ROS. Many blockades, to include the ability to get user by username vs. user identity.
Just throwing out an idea but you could setup the first register/login which will act as the admin of a clinic. This triggers creating a Realm at /<admin_user_id>/accessRequests which is accessible to all users (so a PermissionChange would need to be created to open this to all users). In addition, this would create: /<admin_user_id>/sharedClinicData.
Other clinicians at the clinic can register/login but they must also specify the admin user ID. You could imagine the admin user would email the other expected users of the app and say please register with my ID so that you can be added to my clinic.
When the other users login (with a given admin ID specified), the app would then open /<admin_user_id>/accessRequests (using the specified ID) and create an AccessRequest object in the Realm with their user ID.
The app should then allow the admin user to view AccessRequest objects in their scoped accessRequests realm. When new objects come in the app can allow the admin to grant access, which would mean creating a PermissionChange object to grant access to the user to /<admin_user_id>/sharedClinicData.
I think this gets you close to what you are looking for.
Yes this is exactly what I sketched out as well. It is a few more moving parts than I wanted, but this at least validates it for me. There is quite a bit of logic and UI work to be done going this route.
I also saw your response to a similar question on SO about PermissionOffer and PermissionOfferResponse. That sounds right up my alley, if I read correctly. Sounds like this could remove a few of the above steps? We are launching at the end of January, so I'm pressed to not write the above code only to have to unwind it for this new API. If indeed we are looking at a few weeks, it would be worth the risk to me ;)
You guys rock. Thanks for the massive undertaking with making ROS! This is the most important SDK for me to track (almost daily). In the iOS world at least, you've pretty much schooled Apple in how SDK's should be supported, even in beta phases.