I am developing an app that makes use of Chrome's Bluetooth API. The development is highly annoying because everytime I change my code, the page reloads and I need to request permissions to connect to the Bluetooth device again and those permissions can only be granted through a manual process of clicking through an interface
const device = await navigator.bluetooth.requestDevice(options);
will trigger this (sorry the screenshot is german)
It is not possible to save and restore the permissions for Bluetooth
navigator.permissions.query({name:'bluetooth'})
this is intended to be possible someday but it's a work in progress in the chromium project.
Now I wonder, is it in any way possible to change settings in chrome to loosen a security setting to allow me to just access bluetooth without having be be granted access? Not via JavaScript but by maybe through some setting in Chrome or some sudo command I can execute?
Apologies for the very late response to this question.
I recently implemented a new permissions backend as well as two APIs that will enable previously permitted Bluetooth devices to be used.
The new permissions backend is implemented behind the chrome://flags/#enable-web-bluetooth-new-permissions-backend. The new backend will persist device permissions granted through requestDevice() until the permission is reset in Site Settings or the Page Info dialog box.
The getDevices() and watchAdvertisements() are implemented behind the chrome://flags/#enable-experimental-web-platform-features flag for Chrome 85.0.4165.0 or greater. The recommended use of these APIs is to use getDevices() to retrieve an array of permitted BluetoothDevices and then calling watchAdvertisements() on these devices to start a scan. When advertisement packets are detected from the devices, the advertisementreceived Event will be fired on the device that it corresponds to. At this point, the Bluetooth device is in range and can be connected to.
Please give this new feature a try, and file any bugs at https://crbug.com using the Blink>Bluetooth component.
Related
I have the following case in a web application of mine. The usual browser that the user uses is Chrome.
I use digital certificates that users have cryptographic cards that they insert into a card reader.
To log in to the application, basically users access the https link that makes the certificate data read.
So far everything works fine.
If the user to end his session of the application closes the browser, there is no problem. Everything is over.
But if the user wants to leave his application session, without closing all browser windows, here are my problems.
There is a button that closes the session of the application, the user leaves and redirects to the initial login screen. It seems that everything has been reset, because the user has left. But when the new user wants to log in and press the link to read the certificate data, instead of doing a new reading of the new card, use the data from the previous card without just asking for the pin to access it.
The problem goes further, for example, if the user has forgotten the card, the card and tries to logarize, the failure to read the certificate. But now, although inserted correctly, the card will not be read again until the browser is restarted, which maintains a cache that does not have a certificate.
At the moment only the solution was found by closing all Chrome windows, but that depends on whether the user does or not.
A partial solution would be sure to close the browser with javascript () but for some time, it can not be closed with javascript (window.close ()), a window that can not be opened from the site itself, with what is available I think it's ruled out
Can someone contribute to me? Thank you
Chrome and the rest of browsers maintain a cache of the SSL authentications performed and decide when to prompt user for selecting a certificate. There is no "logout" function neither the connection can be closed from server side due to TLS resumption protocol ( client can resume the session)
This a common and known issue when defining an authentication system using client certificates. I only have found a workaround: use different domains to force browser to choose a certificate:
login.domain.com
-->login1.domain.com
-->login2.domain.com
-->loginN.domain.com
You have a virtual authentication URL login.domain.com which redirects user's browser to a random loginN.domain.com every time you need an authentication. Chrome will detect that it is a different domain and will prompt user for selecting a certificate
You could also think about using different ports instead of different DNS, but then you could have problems with the user's firewall because you are not using a standard port, and in this case Firefox does not show the window either.
Please I developed my mobile app and is primarily using localStorage for storing account info and some other info. The app has mobile and browser version.
For the browser version, I expect a user that is logged in to not be redirected to an auth page on browser restart. This works fine as my info are stored in localStorage. On the other hand, my mobile doesn't. User have to log in whenever he restart the app.
Please what option do I have? What option do developers use for the mobile storage? Do I have to use database? If so which one should use and where can I find a better documentation on this topic?
Note: I am using Cordova for my mobile app development framework.
For some reason, localStorage is tied to browser history. Some mobile browsers have an option to erase browser history on exit. If that box has a checkmark in it, then localStorage gets purged along with browser history everytime the browser is closed! So, you can ask the user to go into Settings and uncheck that box. Note: localStorage is not supported by older IE browsers, Opera Mini, and some Blackberry devices.
If cookies are enabled, you could use a one-time cookie code to log the user in automatically, but that cookie must expire after first use. Once the user is logged in, the server must issue a new cookie code to the client. And the client can use that new cookie to log in once again or keep alive the session. Using the same cookie twice should not work for security reasons. And the server must make sure never to issue the same code to two different users!
I remember, about 10 yrs ago, I went online to check my emails, and immediately the site had me logged into another user's account! I could have read that person's private emails and stuff, but I decided not to. I reported the incident to the admin. The problem was probably their server issued a random quick-login access code to me, and another user somehow got the same access code that I got. And when I opened the website, it thought that I was that other person. If your site deals with money and credit cards, you should avoid this technique! Any kind of auto login is a bad idea for a bank!
There is a plug-in to store data in an SQLite database using Cordova in this link
. You can find more details about storage with Cordova in the doc.
Save your data by using the following:
localStorage.setItem("variable", value);
Retrieve it from localstorage by using the following:
localStorage.getItem("variable");
It is as simple as it is.
Reference here.
Chrome is auto-filling the credentials, but not log me in until I click login. How to automate? (windows, non-google websites).
Using the Chrome Identity API you can have Chrome (on desktop and Android) automatically attempt to log in the user when they hit your page, even if their session has expired.
Following is a workflow diagram of how it works, but the details can be found in the Google Authentication API: Let the user automatically sign back in section:
It is not the browser's responsibility to auto-login to websites. This is the responsibility of the website you are accessing. The browser can remember form data and auto-fill for you, as can various extensions like LastPass.
However, in order to actually auto-login, you must first login to the website you are trying to access and enable the option they provide, often called 'Remember me?'. The website would typically use a cookie to store the credentials (securely with a hash + salt), and if the cookie still exists (not cleared from the browser or expired), and the hash of real password in database matches the one in the cookie, the website will auto-login.
You could force the browser to try and auto-login with extensions, which are essentially macros. You could try Auto Login or iMacros extensions for this. I would generally avoid this though.
Anyone else stumbling into this thread from a google search.... you can do this with autohotkey. If you browse to yourbankhere.com and chrome fills in the user/pass, you can have autohotkey perform a mousemove then a mouseclick to click the login button.
I'm building a Chrome kiosk app that will be in a public space. Users can interact with the app, but there are a variety of settings (server addresses, timeouts, etc.) that need to be set. I'm looking for a strategy on how to allow access to that administration config.
On first run - This is straightforward, but I want administrators to be able to pull it up again.
Detect if the app ran as a kiosk app or manually - This would kind of work, not sure if it's the greatest
Detect some key combination - Ctrl + Alt + Something switches over to the settings page, this feels like people could stumble on it accidentally.
Is there another approach I'm missing?
If your Chrome device(s) is managed you have a further option which is to use the Chrome App Management area within the Google Apps admin interface.
To do this you code your app to use the storage.managed API and this should allow a Configure section for your app within Chrome App Management.
I haven't tried this myself yet but this appears to be the way the Chrome Sign Builder app is configured with its schedule.
Another approach would be to have an administrator login button in a corner of the app. You can set a default password for administrators, which could then be changed in the settings dialog.
You can also think of combining suggestions you have made, first run and then a key combination, and this could bring up a password prompt as also suggested. For an example of this see the Zebradog Kiosk app which is in GitHub so you can see code of how this could be done.
I use ctrl-alt-S at boot. This allows me to login and make changes. I know you have to do a couple of reboots, but it is out of service during admin time anyway.
The Windows Phone documentation states:
The app must first describe the notifications to be provided and obtain the user’s express permission (opt-in), and must provide a mechanism through which the user can opt out of receiving push notifications.
In iOS and Android it would appear that simply registering an app for notifications will prompt the OS to take care of prompting the user for permission and allowing the user to change this.
How do you do this in Windows Phone 8? Does the app have to:
prompt for permission on first use
provide a setting to opt out
Or is Windows Phone just like Android and iOS and the OS takes care of things for you?
From the phrasing of must provide a mechanism through which the user can opt out, it seems there is no built in mechanism implemented by Windows Phone.
Therefore I assume that you should have some settings menu which specifies which push notifications your app wants to send and allows the user of the app to opt-out by un-checking the relevant check boxes.
That's not very different from Android. While newer versions of Android provide a settings option that disables all notifications for a specific app, individual apps might still want to supply an options menu that controls the frequency and type of notifications the user is willing to accept. BTW, in Android the only prompt the user gets about push notifications is in the list of permissions required by the app, so if they choose to install the app, push notifications are automatically enabled (assuming the app registers to GCM immediately), so it's not the same as the alert you get in iOS which asks you to allow push notifications.