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.
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.
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.
Whenever I try to visit log in to PayPal on Google Chrome (my current version is 35.0.1916.114 which is the most up to date at the time of writing this), I get a 500 Internal Server Error. Here's the exact one:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#paypal.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
I'm able to visit the homepage fine and I can log in on all other browsers but this has been an issue for some time now (I just haven't gotten around to looking into it). At the moment, I open Firefox just to use PayPal but I used Chrome for everything else so I'm trying to solve it.
Any ideas on why this would be happening? I've seen other questions on the web similar but they are mainly due to people 'buying' through PayPal which isn't a problem for me. I can purchase items on the 'purchase' screens that you get redirected to from a site.
Thanks for your help!
I see this from time to time on a couple of very specific web sites (e.g., Slashdot). All other sites works fine when this happens (and the site works fine in other browsers, including Web Kit based ones). The embarrassingly simple solution is to restart the browser (I try to avoid it since I often have 50+ tabs open). If guess the problem might be session cookies (that would explain why a restart works). As a consequence of this guess, clearing all permanent cookies for PayPal and related sites might be worth considering.
For me, I do like this at the 500 error page
Click on the Secure to the left side of the address bar
Select Site settings
Select Reset site settings at the bottom of the page
Reload the page
in some cases but not all. There appears to be a corrupt session via the cookie or data stored for a specific browser in the java files. Try the following;
1. Download CCleaner (close chrome)
Remove and clean registry files
Remove tmp and cached for CHROME as well as cookies
Clear index.dat file
4. Control Panel / Java-open / clear internet java cached files
5. Make sure you're not using a proxy IP for the web
6. Restart computer
7. Try again
Now that Google separated cookies from permissions I had to delete my cookies separately to get it to work.
Click on the Secure to the left side of the address bar
Select Cookies
Select the wordpress cookies and Remove each one
Reload page
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.
Trying to set up an encrypted connection for an intranet site. It's for a small company and not dealing with any sensitive information, but still would like to avoid login and password information sending in the clear. Would also like to avoid having to buy a certificate if possible.
I tried creating a certificate with OpenSSL and got everything set up and the site works over an HTTPS connection, but the web browsers are all showing warning messages. So, I googled around and found that I could add the certificate to Windows' Trusted Root Certification Authorities. I tried this, but am still getting the warning messages and "red x" https logo. Also tried importing the certificate into Chrome through the options screen but no luck.
How can I get my internal machines to trust my self-signed SSL certificate and not show a warning message?
I think Mr. Leahy's suggestion to use a name with DNS-like qualification would work. Here's Chromium patch information related to the error:
http://groups.google.com/a/chromium.org/group/chromium-checkins/msg/9fe59a981479aa44?pli=1 (r62178)
If the host name denotes an "intranet host", which in the code means one with either no dot in the name or a dot at the end, then it is considered non-unique, and you get the warning. After quickly looking through other patches involving the warning, I didn't find a way to tell Chrome to relax about the warning.
Im not sure this will apply to your question but I had a similar experience a few days back where chrome would show an insecure site (red cross through the EV ssl)
In my case it was because some links from google apis were over http not https
thus MAKE SURE ALL YOUR EXTERNAL RESOURCES ARE CALLED OVER HTTPS not http!
I stumbled across the same issue today and found a stunningly simple solution:
It turns out that a bad certificate override is displayed during the entire chrome session even if the certificate has been validated or renewed in the meantime.
Restarting chrome fixes that.
If the certificate warning is still present after the restart, then You will have to look at the other answers.