I have a strange issue, we are running a asp.net core razor app.
There are no issues logging into Firefox or Edge.
But rather randomly, we have an issue in Chrome that we can't figure out.
(Random as in, it has occurred on user's machines randomly before and now it is occurring on a lot of machines, but still not all of them)
The issue is that it seems that our "auth-token" cookie is not being set.
To me, it seems that the error is with this line which runs after a successful username and password, but before a redirect.
...
Response.Cookies.Append("auth-token", inToken, option);
...
There is no error, but a line that runs almost immediately after falls over
public async Task Invoke(HttpContext context)
{
var name = "auth-token";
var cookie = context.Request.Cookies[name]; //THIS LINE DOESN'T HAVE THE COOKIE CALLED "auth-token" IN CHROME
...
}
We have tried:
Incognito Chrome/Clearing Cache/Cookies in Chrome
Restarting Machine
Uninstalling and Reinstalling chrome
Installing old versions of Chrome (chromium)
Running an old version of our code (which previously worked on chrome)
There doesn't seem to be a clear cause for when this issue occurs.
I would love to figure out why this is happening or if possible any information on how I could capture what is happening.
Thank you!
After many hours researching it seems I have finally fixed my issue.
By setting the following in our cookie
SameSite = SameSiteMode.Lax
or
SameSite = SameSiteMode.Strict
Our Chrome issues have been fixed
I was reading about Google Chrome's "SameSite" cookie options.
https://www.chromium.org/updates/same-site
Originally I thought this was unrelated as SameSite has been forced in Chrome for quite a wile now, and it has never bothered our code. But I still tried setting:
SameSite = SameSiteMode.None
To no changes
After bringing this up to my boss he informed me that he noticed an old warning that appeared in the chrome console for <1 second.
'A cookie associated with a resource at ... was set with
'SameSite=None' but without 'Secure'. It has been blocked....'
(Note: This was before I tried messing around with SameSite Options at all and was part of some code to fix a Safari bug)
So naturally we managed to capture the error with a quick screenshot and then we added in the SameSite option with Strict.
So I while it works for me now it still doesn't explain;
Why didn't it break earlier, we have been using versions of chrome with it for several months
Why does it still not break if I run an old version of the code with .net 2.1 (without any SameSite Options adjusted)
Why does our new version of the code without the adjusted SameSite option still work on some user's machines
While I'm trying to visit a specific website (that one: https://login.uj.edu.pl) I'm getting ERR_INVALID_ARGUMENT error. Here is the problem: "Server has a weak ephemeral Diffie-Hellman public key".
More about the issue there: https://productforums.google.com/forum/#!topic/chrome/o3vZD-Mg2Ic
I know that it should be fixed by a webmaster but until it happens I have to access the page every day anyway. I found an extension to Firefox to avoid this error: https://addons.mozilla.org/en-us/firefox/addon/disable-dhe/
Now i want to get rid of the error in Google Chrome (well, Chromium actually). Is there any possibility to make it work? It's my university's page and it can take years for the site administrator to fix that secure connection issue.
What's strange the problem occurs in Linux only, in all the browsers. In Windows, Chrome-OS or Android there is nothing wrong. I know that using insecure connection is wrong but in that case I have no choice.
EDIT:
I cannot accept any solution because the site I was trying to access changed its encryption to the right one. Now I can't test your solutions because the problem is already solved by site admins.
The solution is:
Type in your browser (I tried in Iceweasel)
about:config
Search for
security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha
Set them both to false (just double click to set them to false or true).
That's it!
This solution worked for me:
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
The recent release (Sep. 1) to Chrome 45 contains the fix for the Logjam attack as detailed in https://weakdh.org but it introduce this kind of problem.
I found it in this post
Quick hack to get around this issue (Mac OSX)
Run this in commandline to workaround the issue while launching Chrome
Chrome:
open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
Canary:
open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
For Firefox
Go to about:config
Search for security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha
Set them both to false.
NOTE: Permanently fix would be to update the DH key with a length > 1024
Are you by any chance on the Chrome development channel, or possibly the Beta channel? I know that the dev channel currently has some stricter rules on SSL keys, and Beta might as well. You might try getting the stable release from https://www.chromium.org/getting-involved/dev-channel and see if that runs without the error.
Use netsurf (netsurf aur) on that site. I am on the same boat with you. Using Arch and Chromium and Firefox both refuses to enter certain websites. Netsurf can do the job for me.
I have also facing this issue and resolved by #Duccio Fabbri answer,
--cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
I don't know why this works but it works, for permanent use of this you can follow below step.
Go to browser short cut
Right click and Go to properties
Go to Short cut tab
Go to Target textbox, in this you will find your chrome full path , add above string at the end of path.
and it will look like
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
Apply and close it.
Now it will work.when you open it next time.
At Fireforx I was facing the same problem, I did the following changes and it worked for me,
Firefox:
Go to about:config from browser tab
Search for security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha parameter.
Set them both to false.
I was also getting this error, I reset the chrome settings to fix it: Settings > show advanced settings > Reset setting
I found the solution for apache tomcat in this stackoverflow question, I just copy the solution:
Just edit 'conf/server.xml' adding the 'ciphers' attribute to your https connector:
<Connector
...
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA"
...
Practically you're explicitly defining the list of allowed ciphers, excluding the Diffie-Hellman ones (the one with 'DHE' in the name).
Open Server.xml file in your tomcat and set attribute "ciphers"
<Connector port="8007" protocol="AJP/1.3" redirectPort="8443" ciphers="SSL_RSA_WITH_RC4_128_SHA" />
We have a page that uses html5 geolocation, which seemed to stop working early this morning for desktop users of Firefox and Google Chrome, but IE9 still seems to work. If I am on a wireless laptop/device it works fine. If I go to a desktop computer using ethernet, and try with Firefox or Google Chrome, it will ask me if I want to allow the browser to share my location, and I click Yes, the browser doesn't to anything. If I do the same thing with IE9, it locates me fine. This was working fine yesterday, and seems to have stopped working around 1:00 AM EST. Any ideas or suggestions?
thanks!
This appears to be an issue with the latest version of Chrome (33.0.1750.154 m). It started happening to me as well.
Here's the documented issue. Scroll down to the latest entries.
Today (18 minutes ago)
Yesterday geolocation on Chrome Version 33.0.1750.152 was working fine. Now, navigator.geolocation.getCurrentPosition( successCallback, errorCallback ) is always triggering errorCallback when running on localhost. Getting the following error: PositionError {message: "Network location provider at 'https://www.googleapis.com/' : Returned error code 404.", code: 2, PERMISSION_DENIED: 1, POSITION_UNAVAILABLE: 2, TIMEOUT: 3}.
The cause is that, to enhance user privacy, Google Chrome and most other browsers now require SSL/TLS (https://, not http://) with at least a self-signed certificate before they will allow getCurrentPosition or watchCurrentPosition to return any results. No error visible to the user is generated if unencrypted http:// is used — it just returns empty results (some browsers may indicate a “Blocked” error in the JavaScript Debugging Console, but that’s only visible in the Developer Tools). Chrome was one of the first to do this, but now nearly all modern browsers do likewise.
Install a free GetEncrypt certificate (or full certificate if desirable for uses such as eCommerce) on your server and force SSL on at least that page, and it should work. Self-signed can be used for test purposes only and will generate a browser security alert that must be bypassed.
I want to make a video platform.
I am experimenting with WebRTC, running nodejs as a server.
Now the problem is that I have Chrome 21 in Ubuntu goes as it should, no errors at all, but in Chrome 23 (in Windows), I hace an error at client side.
Here is my code
if(typeof webkitPeerConnection === 'function')
pc = new webkitPeerConnection("NONE", onSignalingMessage);
else
pc = new webkitDeprecatedPeerConnection("NONE", onSignalingMessage);
The error happens to try to use the function webkitDeprecatedPeerConnection. It says webkitDeprecatedPeerConnection is an undefined function, it means, it does not exists.
Also, PeerConnection flag is enabled.
Linux Ubuntu 12 (32 bits)
Windows 7 Ultimate (64 bits)
PS: Excuse me for my english, my native language is Spanish.
You can see that webkitDeprecatedPeerConnection is no longer supported on Chrome, right now!!
We now have a new W3C editor's draft to work with. This draft, which
can be found at http://dev.w3.org/2011/webrtc/editor/webrtc.html ,
makes it possible for us to move forward with our implementation of
PeerConnection.
To keep the code base manageable, we will be removing
DeprecatedPeerConnection from the API. This change will affect Canary
and Dev versions soon. The newer JSEP API provides greater flexibility
and allows for easier encapsulation of other protocols. A lot has been
written about it.
For those that want a quick transition to the new API, we recommend
using the ROAP to JSEP JS library created by one of our colleagues. It
abstracts DeprecatedPeerConnection while using the newer JSEP API. It
can be found here:
http://code.google.com/p/webrtc-samples/source/browse/#svn%2Ftrunk%2Froap-jsep
Thanks,
/Serge
Okay, so I'm a student programmer in my college's IT department, and I'm doing browser compatibility for a web form my boss wrote. I need the user to be able to open a local file from a shared drive with a single click.
The problem is that Firefox and Chrome don't allow that for security reasons. Thus, I'm trying to write a custom protocol of my own to open an address in Internet Explorer regardless of the browser being used.
Can anyone help me with this? I'd also be willing to try an alternative solution to the problem.
The below worked for me, is this what you mean?
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo]
#="URL: foo Protocol"
"URL Protocol"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\DefaultIcon]
#="C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\foo\shell\open\command]
#="C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe \"%1\""
Just to note, I'm running Win7Pro, so you may have to move around file path(s) to conform to your environment.
And if that doesn't work, create a proxy between the protocol and the browser, pass the argument(s) from foo:// to that, parse what's necessary, then hand it off to IE using start iexplorer.exe "args".
I'm unsure whether I understand your question, if it is how do I open local files using chrome/firefox, this is your anwser:
First a disclaimer, I have never done this and cannot vouch for the accuracy of my response
IE
Microsoft's security model is pretty fail so you can go right ahead and open these files
FireFox
Some quick googling found that Firefox can do this after either editing prefs.js as outlined here or installing an addon called LocalLink
Chrome
Practically impossible due to its security, until now when locallink was ported to chrome.