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.
Related
I want to explain users requirement of allowing permissions i.e., opt in
Starting from android 13 users are asked to opt-in for notifications.How can we handle this scenario.
Currently i want explain users importance of allowing notifications but what is the best way to show this message as the permission dialog is loading on app start immediately.
Google recommends such a user-driven workflow for requesting notification permission for example:
First, you need to show your custom screen where you explain why the user needs the notifications. If he agreed to be notified then you can ask to grant the permission to show the native permission dialog.
Also, the custom screen is necessary only if shouldShowRequestPermissionRationale() returns true because if it's false then it means the user has already blocked it and can allow it again from system settings only.
I am trying to implement a hardware busy light to show my Microsoft Teams presence so that my family to not enter the room I have the office while I am in a meeting. I am looking to implement something similar to:
https://www.eliostruyf.com/diy-building-busy-light-show-microsoft-teams-presence
https://blog.jongallant.com/2014/12/beakn-v0-1-diy-lync-status-light/ (older acticle - similar idea).
The only problem I have with this setup is that I cannot get the MS Teams status.
The best way to go is by using MS Graph Presence API but my problem is that this is a company account and I don't have (and there is no way I could have) and app in the main subscription granted with the required scope: Presence.Read.
So I tried different ideas but none worked in the end:
check local running processes
check if MS Teams exposes any local API
check if there is a CLI available
This seems a simple idea, I mean, I see the status right there now while I am typing this message, I could as well do an app that gets a screenshot of the taskbar and extract the status from the icon, but is that really the only option I have?
I think I found something interesting for you.
Go to
C:\Users\user\AppData\Roaming\Microsoft\Teams
you'll find a file called logs.txt
In this file you see if your current state changed
(current state: Available -> DoNotDisturb)
I would write a script with php or VB (depends on your skills) that read that logs.txt file like every minute and check for the last "current state" line.
What those posts are doing (certainly the first one, I didn't check the 2nd one) is calling the Microsoft Graph, which has a "presence" endpoint to get a user's status. There's actually even a specific "/me" endpoint, to get your own personal preference (less access rights needed). See more about this here: https://learn.microsoft.com/en-us/graph/api/presence-get?view=graph-rest-1.0&tabs=http
In order for this to work, as you've mentioned, you do need to have an Azure AD App registration. However, importantly, this will only require "delegated" permission (i.e. only permission from the single user, you, to access just data for that single user, you). As a result, you can use "delegated" and not "Application" permissions, which means that it does -not- require Admin consent for the tenant.
It -does- require and Azure Add Application though, at the risk of stating the obvious. While you don't have tenant admin rights, you need to see if you have Azure rights, just to create an application (you might have this anyway as a developer in your org). If you don't even have this, you can sign up for an M365 Developer account, and use that tenant. Importantly - the application does't have to be in the same tenant. If it's not, it's just a simple multi-tenant app, like any 3rd party Azure AD-backed application is.
I could not find such answer. Is it possible to keep analytics enabled for all but disable it for one person? Assuming there are no toggles in an app which user can use directly and I want to do that from a back end only when a specif user requests it.
Well, yes, but it's entirely up to you. If your app loads Google Analytics without it being provided by the back-end, you could provide it in a response, say when the user logs in. The response to your auth endpoint could provide some optional data, something like:
{
"success": true,
"token": "abc123xyz",
"useanalytics": false
}
and then your app logic could use that to disable analytics from the client side, without needing an in-app toggle.
One thing to bear in mind – Google Analytics is not strictly necessary for the operation of an app, and is currently illegal to use in the EU (because it ships data to the USA), so I would recommend that if you want to use it, it would have to be enabled explicitly by the user after appropriate warnings. This probably applies to Firebase too.
Im working on an app that requires a PIN to allow certain tasks (purchasing, dealing with credit cards, etc). I would like to add the ability to use biometrics.
I want to be able to ask for permission to use the biometrics without actually authenticating anything the first time.
for example, the flow would be as follows:
- user logs in
creates a PIN
App asks if they would like to use biometrics in the future
next time when PIN is required, authentication prompt appears.
the current flow:
user logs in
creates a PIN
App asks if they would like to use biometrics in the
future
next time when PIN is required, OS prompt appears asking if
user is ok with app using biometrics.
THEN
authentication prompt appears.
Ive played around with react-native-touch-id, react-native-biometrics and a few others.
I know i could have it triggered when i first ask to set the PIN but the system prompt options are not customizable.
Thank you for your input!
Apologies for the general nature of this question. Hoping this doesn't get shot down as "too broad", but oh well, here goes:
I'm writing a React Native app that is purely informational (medical information), with a Rails API for the back-end.
The first main question I have is whether its necessary (or a good idea) to use authentication at all. We don't want the user to have to enter any information to use it (username, password, etc). They should just be able to download the app and jump right in to use it and read the information it provides.
However, I'm thinking that I would at least want the API to only respond to someone hitting it from within the React Native app (or not? Is it considered a normal practice to have an API completely exposed in the case of an app like this which is purely information and doesn't have users, like a website?)
Second - at some point we may want to be able to store some simple preferences for that user (I.E., are they a patient or a doctor, so we can tailor the materials based on that / send them to a different home screen when the open the app). Wondering what strategy someone might use to store simple preferences if the user doesn't ever create an account?
I would at least want the API to only respond to someone hitting it
from within the React Native app.
This probably can't be done, as in a mobile app everyone has access to your client secret and can try to reverse engineer your code.
You could make it more difficult by sending a dynamically generated token to your API on the request, for example, a hash based on a time frame, and check if the hash was sent the correct way. Then, you'd have to obfuscate the code in order to make it difficult for someone to reverse engineer it.
Second - at some point we may want to be able to store some simple
preferences for that user (I.E., are they a patient or a doctor, so we
can tailor the materials based on that / send them to a different home
screen when the open the app). Wondering what strategy someone might
use to store simple preferences if the user doesn't ever create an
account?
If you use a Parse Server instance as your backend, you could benefit from the anonymous user functionality. As you're using a Rails API, you could generate a uuid for each installation of the app and save the preferences on your database based on that uuid. If you don't need those preferences stored on your backend, just store any information you need on the device through any abstraction of AsyncStorage.
I really do not need authentication when it comes down to it - there are no users.
I could verify that the data is coming from my app based on a user agent or a hard coded password. SSL should help keep those secret.
But yeah, there would be nothing preventing someone from disassembling the app and getting that information. Great idea by #felipe-martim about generating a dynamic token.
I really just want to prevent basic abuse, and I could deal with that if it ever happened, or protect myself with something like Rack-attack.
And storing user preferences locally should work just fine for local preferences.
Bottom line is that I'll deal with this if I ever need to / the client budget allows for it!