From what I understand, Realm is a local database while Atlas is the cloud database. When a Synced Realm is opened, it takes either a partition or some subscription queries that determine what data should be synced from Atlas down to the local realm, and any further changes made to the local realm will be synced back up to Atlas.
My question is, is it possible to query for data that is NOT synced in the local realm but exists in Atlas? For example, lets say Atlas contains user information about UserA and UserB. UserA is synced with my local realm, but I also want to query UserB while not wanting UserB to be synced. Is this possible using in the same realm? Thanks
The short answer is yes.
Keep in mind that Realm can sync both via a Partition strategy where everything in the partition sych's or Flex Sync which provides a more fine-grained sync.
The cool thing is that Realm provides several different ways to interact with your data. As you can see the SDK make a lot of that interaction trivial so you can spend more time coding the UI and less time worrying about end-points and callbacks.
Your app can also interact directly with Atlas using Atlas App Services backend which essentially gives direct access to data without syncing.
You can also call Functions which is server based code, to gather up data and return it to your app
There's more info at Query MongoDB - Swift SDK
and for Kotlin, there's the App Services
If you love pinging endpoints directly, you can do that as well with URL Sessions.
Realm provides lots of options - I don't know about your use case but there's often a User partition all users sync with that keeps generally available info about each user - the nice thing there is you can add an observer so if something changes for any user, you're app will know about it.
For example:
A new user signs up and set's their favorite food to Pizza (same as yours) and without lifting a finger you immediately know about that and... pizza party! (this is an example of relying on events instead of polling)
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
GunDB is supposed to support peer-to-peer data access, so I'm trying to better understand how this would work. If I were to build a twitter clone, what would the high-level architecture look like if I wanted each user to store their own tweets on their own server?
Answer by the author of GunDB:
Every tweet is cryptographically signed by the user (in fact, with SEA, all data by that user is signed automatically, so you don't have to worry/do anything!) which means that no matter where it is stored (by the user, by a server, by another user), it cannot be tampered with.
By default with GUN (and you could modify this if you wanted, but you'd be adding a lot of unnecessary complexity, which I don't recommend), the tweets are stored by whoever subscribes to that data. That would mean: (A) the user who made the tweet would store it (B) a server peer, which is subscribed to everything, stores it, (C) and friends/viewers/followers/audience who reads the tweet also stores it.
Realistically, most users probably are using a browser to access their app, so you wouldn't want to assume this is reliable - but you can Electron-ify (or something similar) your app so that users can install it on their desktop, in which case, they would be their own server. Then you (or other users) can also deploy the app to AWS/Heroku/DigitalOcean/whatever and ALSO store data as a backup there (like in the case of B, if you add your S3 credentials, it backs data up to S3 - ideally this would be IPFS instead, or similar), etc.
I have been following your project for quite some time now and am intrigued by the functionality of gunDB where it doesn't require a database in between and keeps security in check.
However, I've got some questions about GunDB which I've been thinking about for quite some time now before I can give Gun a go with a project I'm currently working on. In this project it is necessary that data is safe but should also be shareable once a group has been setup. The project is a mobile app project and ata is mostly stored on the device in a SQLite database.
I have been looking into Gun as it allows for better usage of the app in sense of collaboration. The questions I have, however, are:
User authentication
How is user authentication handled through private keys? So how can a user "register" with, for example, a username and password to login to the service.
For authentication I am currently using Firebase where it is possible to use username/password authentication and I would like to know how Gun approaches this case and how it's implemented.
Data storage
In the documentation and on the website it's stated that data is stored locally with every client and can be stored on a "node" or server using either a local hard drive or the Amazon S3 storage option.
What I am curious about is what data is actually stored at the client? Is this only the data he/she has access to or is this a copy of the whole dataset where the client can only access whatever he/she is granted to have access to?
Maintaining your data
When I've got a production system running with a lot of data, how will I be able to manage my data flows and/or help out my clients with issues they have in the system?
In other words, how can I make sure I can keep up with the system if I want to throw in an update and/or service my clients with data issues.
My main concern is the ability to synchronize their local storage correctly.
Those are all my questions for now.
Thank you very much in advance for providing some clarity on these subjects.
Best regards,
(Answered by Mark Nadal on Github: https://github.com/amark/gun/issues/398#issuecomment-320418285)
#sleever great to hear from you! Thanks for finally jumping into the discussion! :D
User Authentication,
this is currently in alpha. If you haven't already seen these links, check them out:
https://github.com/amark/gun/wiki/auth
http://gun.js.org/explainers/data/security.html
https://github.com/amark/gun/blob/master/sea.js#L23-L43
https://github.com/BrockAtkinson/login-riot-gun
If you have already, would love to either (A) get you to alpha test and help push things forward or (B) hear any specific questions you have about it. This thread is also a more at length discussion about alternative security API ideas: #321 .
Data storage.
Browser peers by default store the data that they subscribe to, not the full data set. You could ask it to store everything, but the browser wouldn't like that. Meanwhile NodeJS peers, especially if hooked up to S3 or others, would store all data and act as a backup.
Does this make data insecure? No, encryption should keep it secure, even if anybody/everybody stores it, the encryption makes it safe. (See [insert link to (1)] for more information).
Maintenance.
You would service your customers by deploying an update to your app code. It would not be ideal for your customers if you could meddle with their data directly. If they wanted you to do that, my recommendation would be that they change their password, give the new password to you, and you login and make any necessary changes. Why? Because if you have admin access to their data, their privacy is fundamentally violated.
I've gotten pretty spoiled by the mature frameworks available in Python (Django/Flask), so as I'm starting to learn Go, I have to wonder if there are any similar frameworks already in existence in Go to django.contrib.auth or Flask-Login?
The main use case is to handle simple user authentication and be able to extend it to accommodate some permissions-based routing within the app.
As far as I know, there are not. The closest out-of-the-box authentication you can probably get is via Google AppEngine, where the user's Google account can be retrieved and certain paths can be scoped for app administrators only.
In a standard Go web server, you will generally need to roll your own auth, but it's not as difficult as it sounds. Many frameworks isolate you from decisions which are actually quite important; in typical Go fashion, you'll need to make these decisions based on the needs of your app, and then pick the existing libraries that are right for you.
Login page
Wherever you need your users to log in, you will probably use an HTML form. These will typically be rendered using the html/template package. To retrieve the values when the form is submitted, use request.FormValue.
Database
There are a number of ways to store user information; on the filesystem with os or in a SQL database using database/sql. There are mature drivers for some NoSQL databases as well, including MongoDB and Redis.
Passwords
To compute and compare hashes to passwords, you'll want to use a preexisting mechanism so that you don't have to reinvent it yourself. For this, the go.crypto subrepository provides a bcrypt package.
Sessions
If you want to store session data, you can use a solution like gorilla/sessions. Based on your security needs, you can store the session data directly in a (optionally secured) cookie or you can store it in a backend an only store a session ID in the cookie.
From the READ.me
Allows your Martini application to support user login via an OAuth 2.0 backend.
https://github.com/martini-contrib/oauth2
I am making an iPad application.
Where I fill some form and submit the save the form data.
Now here is the catch:-
If the the iPad has internet connectivity, data should be sent to back-end database via an API call.
Otherwise It should be saved in the local storage without the user knowing anything.
There is a screen where User sees previously filled forms list, [lats one week or so] which he can edit. Not knowing whether it has synced or not.
Data is synced with back-end when the user comes online and hits a sync button.
I am using Core Data for local Storage and there is a MySQL back-end with a RoR WS API in front.
Now I have multiple questions regarding the implementation of the entity schema design and and caching technique.
I don't want to make things overly complicated.
All suggestions are welcome :)
My Questions
The unique id for each form data is auto-generated at the back-end . So when I have data saved locally and not synced with the back-end, what id , it should be having ?
How long should I keep data in the local storage and when should I delete relatively old data.
Important factor is, user will not always have connectivity, his login state will also be cached into user-defaults.