WebUSB API documentation introduces new powerful feature with name "usb" to permissions infrastructure (https://wicg.github.io/webusb/#permission-api). But when I try to use permissions api to query permissions for "usb":
navigator.permissions.query({name:'usb'})
I got error:
TypeError: Failed to execute 'query' on 'Permissions': The provided value 'usb' is not a valid enum value of type PermissionName.
I use Chrome Version 83.0.4103.97 (Official Build) (64-bit) on Ubuntu. My first question:
Does permissions api support "usb" feature? If yes, what I do wrong in upper code?
Specification on WebUSB defines where to store allowed devices, but it again offered to use permissions infrastructure as I understood (https://wicg.github.io/webusb/#request-the-usb-permission). My second question:
If permissions api not yet support "usb" feature, where/how allowed devices are stored in browser? Can I programmatically get access to this storage?
Can website request user to allow permissions to group of devices (in my case by vid+pid) which not only connected right now, but also can be connected in future? In other words, I want to ask user "Please, let me work with usb devices (with this vid+pid) which you connect in a future, because I don't want to bore you with permission question every time you connect new device of particular type".
Does permissions api support "usb" feature? If yes, what I do wrong in upper code?
No. While the Permissions API integration defined in the specification is implemented in Chromium-based browsers it is not exposed through the Permissions API's query() method. This is tracked by issue 638721 but has not been a priority given the available alternatives.
If permissions api not yet support "usb" feature, where/how allowed devices are stored in browser? Can I programmatically get access to this storage?
Permissions are stored in the browser's user preferences file and internal data structures which are not directly accessible to Javascript. The only way these permissions are currently exposed are through the settings UI (chrome://settings/content/usbDevices) and the navigator.usb.getDevices() method, which only returns allowed devices if they are currently connected.
Can website request user to allow permissions to group of devices (in my case by vid+pid) which not only connected right now, but also can be connected in future? In other words, I want to ask user "Please, let me work with usb devices (with this vid+pid) which you connect in a future, because I don't want to bore you with permission question every time you connect new device of particular type".
No. It is important to the security design of the API that the user make the decision based on the devices currently connected rather than a hypothetical future device.
For enterprise managed devices the WebUsbAllowDevicesForUrls policy allows an administrator to make this type of decision on behalf of their users.
Related
I am about to implement a reception screen view of some data my product holds. This data is not extremely sensitive, but enough so that my customers do not want it just out there on the internet for all to see.
The concept is a smart tv with a built in web browser that displays a webpage hosted by my application. My application requires authentication for all other interaction, but the smart tv does not support authentication. So I would like to secure the page somehow, so it isn't just available for all to see.
The only options I see are:
Security by obscurity. I would really like to avoid this one.
IP Whitelisting. This I could do, but not all my clients have a static IP.
Enter credentials on screen. This is not really feasible and the credentials are lost on reboot. So we cannot do this.
Are there other options I just don't know about.
For límited input devices like TVs where is not easy enter credentials there are some Open Source options like CPA (developed by EBU for Hbbtv Use Cases) than can work for you and you can control the e2e
CPA
Reference Implementation
The autenticacion token can be stored into your SmartTV app until its expiration or client's logout, etc.
There is also
After some research I found that the best option is the OAuth 2.0 Device Authorization Flow.
The gives the user an experience like the one used when setting up Google Chromecast or AppleTV.
https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow
I want to use circuit as a videocall system in a B2C environment in which only the backend call agents are Circuit users (but the end-clients are not!!).
The only way I see to establish a videocall would be by creating a new conversation, get the url guest link and send it to the end-client.
This could be a “not-that-bad” possibility in a PC web portal front end….but in the case of a smartphone app (ie Ionic-Cordova) that link would redirect the end client to the Circuit app download site, forcing the user to install Circuit app which would not be accepted in the general case.
Is there any other possibility to implement a use case like this from Smartphone apps by embedding the guest connectivity in the app making Circuit transparent for the end client? Any possibility by using a pool of dummy Circuit users to be assigned temporarily to the app users?
That's a good question. There are two problems as pointed out by you.
1. SDK cannot be used without an authenticated Circuit user
I.e. the SDK has no support for guest access other than retrieving the guest access link. Workarounds are:
a) use the guest link and have the non-Circuit users join using their Circuit web or mobile client, or
b) create a new conversation each time and use a pool of users. But this workaround does not look intuitive and have actually never tried it in an app.
2. Guest users require Circuit app
Again as pointed out correctly, if going with a) above, the mobile client users would need the Circuit app to join a guest session.
Conclusion
For desktop users 1a is probably the best option. But for mobile users you'd have to try a workaround with a pool of users.
We are aware of these limitation and are looking into a better solution to address your use case. I will update this post once we have more information of the details and timeframe.
For example, if user installed app in more than one devices, and he tries to login from all devices at a same time then I want to restrict him to not to login from any other devices until he going to logout from first device. Only one active login at a time.
How to achieve above from IBM Worklight 6.1 ? Any API are available for same from Client or Adapter side ? Please let me Know.
There is not built-in feature per-se in Worklight that will give you what you want.
What you could do is explore the world of Custom Authenticators and Login Modules.
You will likely need to create custom properties stored in the database, allowing you to identify if a user is already "logged-in", in which case could perhaps either show a message to the user, or have him force-logout.
Either way, you should probably not stick with Worklight 6.1 - that is an extremely old version.
In IBM MobileFirst console, we are able to set Application Access form "Active" to "Access disabled", then the app will be disallow to access to the MFP server.
My question is, can we disallow user to access to the app itself ? [For example: once user launch the app, the app will pop out a message to tell user to download new version]
Is there an client side API for detect whether allow user access to the server ?
My question is, can we disallow user to access to the app itself ?
[For example: once user launch the app, the app will pop out a message
to tell user to download new version]
This scenario is exactly what Remote Disable is doing. You have v1 and v2 deployed on the server and you want to force your user(s) to upgrade from v1 to v2, so your set remote disable on v1... and then the user(s) are forced to confirm and upgrade.
Are you asking to do this only for singular users instead of for everyone at once?
Assuming your have implemented authentication on your application, since you know who is logging in to your backend system then you should be able to customize this by implementing the server-side code to also query the database for the version the specific user is using (you'll need to also make sure to enter this data to the database, I believe), and based on the result to have custom client-side code to fail the login and point the user to the App Store.
As you can imagine, this is not available out-of-the-box...
What is not sufficient with Remote Disable?
I'm trying to use Instapaper's Simple API (http://www.instapaper.com/api/simple).
The API terms of use (http://www.instapaper.com/api/terms) says apps should not store user id and password, and I don't want to store them either. However, it seems that the only way to add a link to a user's Instapaper via simple API is to store the username/password (if the user does have a password).
Am I missing something?
The API terms of use state that:
Apps must not store users’ passwords. Passwords may only be collected for the xAuth token acquisition and must be discarded afterward.
Only the full API uses xAuth tokens. The above sentence doesn't apply to the simple API, since it uses Basic HTTP Authentication.
You still "must make reasonable efforts to prevent passwords from being compromised, and must not disclose passwords to any other services or individuals".
If you are using a native Mac application (like Apple’s Mail client or a third-party mail client like Airmail) there isn’t an easy way to save a link to Instapaper without first opening the link in a browser and then using one of Instapaper’s browser extensions to actually save the article.
One workaround that I’ve found to expedite this task is to write a service for OS X which uses Instapaper’s API to save links.
In order to write your own service, first open Apple’s Automator application and create a new Service. Then, drag the Run Shell Script action into the application’s main workflow area.
Make sure the service receives no input, can be used by any application, and that the shell script is set to run python.