Once a user has allowed for a getUserMedia request to access their camera/microphone, is it possible to programmatically "remember" that permission across future page loads?
Not sure this answers your question, but for Chrome at least, if you use HTTPS, permission is only requested once. (Looks like this isn't implemented in Firefox.)
For Chrome apps you can add audioCapture and videoCapture permissions, which mean the user is only asked for permission on installation.
Related
I currently have notifications added as an optional_permission for my Chrome extension.
If I change that to a required permission, what will happen to the users that have already accepted notifications? Will they still have the extension disabled for them? Will it be a seamless transition?
Related Links: extension permissions, extension permission warnings
Judging by the source code there won't be a warning for users that have already accepted notifications because the update routine accounts for these runtime-granted permissions explicitly.
But if you add several permissions of which some aren't yet granted, the extension will be disabled.
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.
When using chrome.webNavigation the webNavigation permission is needed. As stated on Permission Warnings, using that permission makes the installer to show the warning message:
Read your browsing history
In my case, I only want to listen to one specific domain, let's say domain.com. So, I need to filter the callback for chrome.webNavigation.onCompleted.addListener().
Now, from the user perspective, they could distrust the chrome extension since "Read your browsing history" is too broad and the extension should only work on domain.com.
When a match pattern is used in the permissions, a message like Read and change your data on all domain.com sites and www.domain.com is used.
Is there any other way to use chrome.webNavigation and only listen to one domain? where chrome extension issues/feature requests should be sent?
Update: I had to use webNavigation in order to support AJAX calls. That is, listen to changes in the DOM and the URL made with AJAX. I solved this particular case by using a MutationObserver. Thus, I could remove the permission. The original question was already reported as a bug by Rob W.
In this case, I've already posted a feature request over a year ago: https://crbug.com/431108 ("Allow extensions to use webNavigation API without webNavigation permission").
where chrome extension issues/feature requests should be sent?
Report feature requests and bugs at https://crbug.com/new (points to https://bugs.chromium.org).
If you want to get the equivalent effect of chrome.webNavigation.onCompleted without using the webNavigation API or adding extra permissions, then you can declare a content script and send a message to the background page when the window.onload event fires.
I developed a chrome extension which communicates with IP phones.
The communication is done in a event page which is sending POST requests via the XMLHttpRequest object.
Because the hostname or IP address of the phone is configured in the options page I added optional_permissions to the manifest file and request them from the user after saving the options with chrome.permissions.request.
Cross-Origin XHR works now without any problems until I restart chrome...
After restarting chrome it seems like the requested permission is lost and I get the typical
is not allowed by Access-Control-Allow-Origin error.
When I click on the extensions permissions I can also see that my requested permission is no longer listed.
Because the chrome.permissions.request is only working for a user gesture I can't request it during the load of my extension or on the fly. If I request the permission again in my options page I don't get asked again whether I want to allow it or not put the permission is granted and everything works again as usual.
Is there a way to get this permission granted persistent after requesting it? I only want the extension to have access to the endpoints it needs.
Thank you very much.
For me the following reported issue answered my question:
Issue 158004: chrome.permissions.request support for user-supplied URL.
To make it clear: It is not possible to request a subset of the permissions defined in optional_permissions. If you define http://*/* then you need to request exactly this string! A subset like http://example.org/* wont work!
Here is a quote from a comment in the issue description which makes that clear:
"There's no wildcard handling, just plain string comparison between the URLPatterns"
The Issue has been fixed in Revision 182287
The only thing left is to cross your fingers that this fix gets included in a upcomming chrome release soon. We'll have to use the bloody Access your data on all websites permission in the meanwhile.
I was doing some research on how Firefox and Chrome are implementing HSTS (HTTP Strict Transport Security) in detail.
Turns out that they have a predefined list with some sites that already implement HSTS. This can be seen here here and/or here.
And these list seems to be somehow linked to the sourcecode itself which makes somehow sense...but how do Firefox and Chrome handle my own HSTS headers? How and where do they store my URL, my max-age and whether I includeSubDomains or not?
I wasn't able to find this in about:config or likewise....
So maybe somebody knows more about this issue than me, I'm just curious (:
Thx!
See http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/netwerk/protocol/http/nsHttpChannel.cpp#l1072 and then http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l249 which calls http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l147
So the data ends up stored in the permission manager, which is the normal place per-host information gets stored in Firefox. The permission manager stores its state in permissions.sqlite, I think.
Sites that want HTTP Strict Transport Security (HSTS) enforced send a header in response - Strict-Transport-Security: max-age=31536000
max age being time for it to expire. It is sent on each request so that it gets updated to that much more time every time it is requested.
Browser (I have tried only Firefox) stores this data with it and will use it every time the site is accessed. This is true even for incognito mode. If you have ever accessed the site before in non incognito mode then the details of that site is saved and used even if you try to open it now in incognito mode.
For firefox this data is stored in a file called SiteSecurityServiceState.txt which is in your firefox profile folder. You can enter about:support in browser and then select "Show in folder" to open your profile folder where you can locate this file.
I am not sure about predefined sites but above is the file where normal site HSTS details are updated for firefox.
More details - Understanding HTTP Strict Transport Security (HSTS)
PS: Above link goes to my personal blog that has more details on HSTS.