1 Why would AWS use/depend on local storage for tracking/remembering device? In our use case, we need to clear local storage every time the user logs out. How can we possibly take care of remembered device then?
2 If I want a device to be enabled only for 30 days or 15 days, how can I achieve that?
AWS Cognito doesn't depend on local storage for tracking/remember device. Take a look on Cognito:Userpool DeviceConfiguration setting in Cloudformation. Cognito can keep track of all the devices. Here's sample code
DeviceConfiguration:
ChallengeRequiredOnNewDevice: False
DeviceOnlyRememberedOnUserPrompt: False
Related
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)
I have a chat application with the option to search for users by name/phone etc.
As part of the design there is an avatar presents the user's profile image.
I store the images in encrypted S3 bucket with private access only.
In order to watch an image I'm using the aws sdk to pre-sign the url with expiration of few seconds.
I'm asking myself if this is a right thing to do, or it's an overkill to do that by the face that this is a profile image and probably a lot of users will see that list too many time in the app, and each list contains few users with their avatars so it is crating a lot of pre signed urls in short time.
What would you suggest?
If your application is a SaaS and/or needs SOC2 compliance(or another maybe), you should go for it. Because they don't allow any public S3 buckets used by your application AFAIK.
I have a requirement to be able to specify session timeouts on a per user basis. (So that it may be a different value for each user) It seems natural to use the 'exp' property on the access token to accomplish this, (as that it's purpose in the oauth spec), but cognito seems to ignore updates to this in the preTokenGeneration trigger. Is there a way to update this on a per user basis? Or do I really need to define some custom attribute that will be checked on the Id token?
Great question. I'm sure you know that since August 2020 Cognito allows you to configure access token expiry time from 5 mins to 1 day. The configuration is per app client. If you were able to split your users across app clients that could be an option (e.g. admins with long sessions login on one page, normal users on another). You could lock the app clients down to certain users using a pre-authentication trigger. That's not a very configurable solution though.
I also wonder what you mean exactly by a session? For example, this would typically mean one of two things. Either your session expires and you have to login again after a fixed length of time (e.g. AWS is 24 hours). Or if you are idle for a certain amount of time (say 30 mins) your session is ended. Could you elaborate on your requirement a bit?
Regarding the MediaDevices API.
(https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia)
I know I need permission to use a media device to capture video, however I am not sure if I need to request permission multiple times in order to capture videoshots at regular intervals or just the one time at the start?
In other words, when does the permission expire? When the stream is closed, browser is refreshed or something else?
Can I use the initial permission to capture subsequent videoshots or do I need permission for each videoshot I intend to capture.
The browser continues to store the settings for device access, so you only need to approve it the first time. Unless you reset the settings yourself.
For example in chrome, you can check the permission of the site at the address below.
cam : chrome://settings/content/camera
mic :chrome://settings/content/microphone
According to getUserMedia docs:
First, getUserMedia() must always get user permission before opening any media gathering input such as a webcam or microphone. Browsers may offer a once-per-domain permission feature, but they must ask at least the first time, and the user must specifically grant ongoing permission if they choose to do so.
So we can see that the user must explicitly choose to grant the ongoing permission option from the pop-up, otherwise, it's going to ask every time.
The permissions pop-up and default selections may vary between browsers though, but they all support this feature.
I decided against using the native browser APIs directly, opting instead to use a service like Twillio to handle video capture AND recording. Once we have the recording I intend to chop it up to get a series of screen shots that summarize the video. This is not in realtime and does not need to be for my application.
I am planning a game app for mobile devices. Users will log into the game using their existing social media account to streamline data capture. Company B would like to directly save player data and scoring information from the mobile app to a DynamoDS table named Score Data When a user saves their game the progress data will be stored to the Game state S3 bucket.
What is the best approach for storing data to DynamoDB and S3?
Option 1: Use an EC2 Instance that is launched with an EC2 role providing access to the Score Data DynamoDB table and the GameState S3 bucket that communicates with the mobile app via web services.
Option 2: Use temporary security credentials that assume a role providing access to the Score Data DynamoDB table and the Game State S3 bucket using web identity federation.
Many architects I talked to Option 1 is the right one. But according to AWS doco, it appears Option2 can be valid too. Any inputs would be appreciated!
I would strongly consider Option #2 using Amazon Cognito to provide temporary credentials to your users that enable them to directly and specifically access DynamoDB and S3.
Generally speaking, you need to:
Create a new Cognito Identity Pool and set up 2 IAM roles -- one for authenticated users and one for unauthenticated users (optional). https://docs.aws.amazon.com/cognito/devguide/getting-started/?platform=ios
Authenticate a user via your own authentication provider or via external providers like Facebook, Twitter, etc., and then use Cognito to create temporary credentials for them. https://docs.aws.amazon.com/cognito/devguide/identity/external-providers/
Use the credentials to access DynamoDB and/or S3. Your AWS resources will be protected as long as you set up your IAM roles appropriately. For example, you can give fine grained access to your DynamoDB table so that users cannot access rows that don't belong to them. See the following link for more details: https://docs.aws.amazon.com/cognito/devguide/identity/concepts/iam-roles/
The Cognito developer guide is here: https://docs.aws.amazon.com/cognito/devguide/.