We have a browser-based upload form, using the client login authentication. Everything works fine in IE, Chrome, and used to work fine in FF till version 18. Our site uses HTTPS, and we are forced to use SSL connection for the YouTube connection as well.
The strange thing is that upload works in FF when using HTTP connection, but, unfortunately, we cannot use it. With HTTPS connection we get the token and the upload url without any issues, but when we do the POST – it just hangs at 0b and nothing happens. Checking in the Net tab we can see that the request is in the waiting stage – there is never a response.
How can we find out what is going on there?
The problem is linked to https and SPDY.
In Firefox 24, disabling SPDY seems to avoid the issue
Go to About:config
search for network.http.spdy.enabled
disable the 3 versions
The bug has been reported to:
https://code.google.com/p/gdata-issues/issues/detail?id=4919
Related
While investigating the (just released) Chrome 80 cookie changes (required SameSite=None for cross-domain cookies), I noticed some strange behavior in one of my applications. The particular application is embedded in another site - the the content is located in www.domain1.com, but the embedded application authenticated and loads from www.domain2.com. We use cookie-based authentication at the moment.
Because of the Chrome 80 cookie changes, we ended up adding SameSite=None to our cookies so that they could be used to authenticate and transfer to www.domain2.com when we made requests via our API. This fixed the Chrome 80 bug we were anticipating, but we discovered that Safari would not work in either iOS (versions 12 and 13 were tested) or Mac OS (versions 10.15 and 10.15). We narrowed the issue down to a default setting in iOS and Mac OS - the "Prevent cross-site tracking" checkbox in Safari preferences. Whenever that box is checked, our cookies do not transfer from domain1 to domain to, even when SameSite=None is set. This seems like it could potentially cause issues for a lot of different platforms, as prior to recently most sites expected cookies to be able to transfer this way.
Is this intentional behavior, or do we have something set up wrong? I've read about other applications having this problem, but have not found any solutions other than hacks like redirecting to a page on domain2 prior to loading the content on domain1, which isn't really an option for us. Is there some way to get around this, or a way to correct our setup so that we can actually pass cookies as we need?
Here's an example cookie that we receive back from our API during authentication:
"thirdPartyBlocked=1; expires=Tue, 09-Feb-2020 01:59:04 GMT; path=/{our app path}/; Secure; HttpOnly; SameSite=none"
This cookie works and transfers as expected in every browser other than Safari. Any ways to fix this issue?
I recently downgraded one of my Heroku apps to a free dyno - as a result, the SSL was revoked (cos I was using the SSL provided with a paid dyno). Now, when I visit my site URL, it gives me this error: ERR_SSL_PROTOCOL_ERROR
I've edited my production.rb file to set: config.force_ssl = false and published that code, but it still redirects my site to https when I try to connect on http.
Now, to complicate things:
This only applies to my custom domain - the .herokuapp.com domain works fine
It works fine on incognito mode on both the custom domain and the herokuapp.com domain
I've tried clearing the cookies and cache (for the last 7 days) and it still didn't work :/
Any ideas what I can do?
Edit:
In case it helps, I am using Chrome on Windows 10
Given that you are using Chrome, according to this answer, you need to follow these steps to stop Chrome from redirecting http:// to https://.
Anon is right about STS, but there is a way to specifically delete your domain from the set. Go to chrome://net-internals/#hsts. Enter 3rdrevolution.com under Delete domain security policies and press the Delete button.
Now go to chrome://settings/clearBrowserData, tick the box Cached images and files and press click the button Clear data.
I have a mobile app that is using ODIC authorization code flow. Our server implementation is using Identity Server 4.
The mobile app opens a browser window and I can login to a 3rd party provider just fine, it then redirects to /signin-adfs on our identity server, which sets some idsrv.external cookies and returns a 302 to /External/Callback. The browser redirects to /External/Callback but doesn't send any of the idsrv.external cookies with it so Identity Server throws an exception because the result from HttpContext.AuthenticateAsync is not successful.
I'm kind of stuck at this point because I'm not a mobile developer. I deployed and have customized Identity Server slightly in other areas but not this part of the code.
I believe the mobile app is opening a Safari session to do the auth. Is this an issue with the cookies that the browser doesn't like (domain, path, https, secure)? or something else? The cookie size is chunked to 4KB a piece. I'm not sure what could be causing this issue.
To make things even weirder... if the browser is refreshed (/External/Callback) then the request works and the iOS app gets the code and can make the follow up request to get the token.
Was digging through the IS4 source and saw a link to this issue on github. Looks like it was fixed in source but hasn't been released yet. There are some workarounds in the github issue if you need it sooner than the release. The problem is specific to iOS 12.
When I access my website, in my QA server for testing, in a desktop using different browsers such as Chrome, Firefox and Safari the website loads just fine. When I try to access the same website using IOS safari, the page redirects in a loop. Im not sure if this is an SSL issue. Im using a self signed SSL certificate. One possible cause of the problem is that the IOS device does not accept self signed SSL.
I tried to research some possible solution. I cleared history and website data of my device and rebooted it but the same result was observed. I tried to access the website without the https prefix but it redirects me to the https website.
Any work around on this?
I have a website that is hosted in apache web server under ubuntu. Now i setup a reverse proxy (ARR) in IIS (windows server 2016) to point the subdirectory (/daily) to the website that is hosted in apache web server - ubuntu. When i try to access the website via safari on iOS, the website is not loading (The loading bar appears on the top-left corner; The loading bar disappears (almost immediately); I am back on the page I was before - The page was not reload, it is as if I did nothing...) however when i try to access it in chrome (laptop, android, pc), firefox, internet explorer and other non-ios browser, i can load the website successfully.This is the twist: when i try to access the website in ios safari using http (not secure), the page was loaded successfully.
I have tried another setup:
Instead of using apache web server for the reverse proxy website, i tried to use different server but this time its hosted in IIS, windows server 2016 and setup the same thing (same SSL certificate, same content). When i try to access this in safari ios (https & http), the page was loaded successfully.
I am guessing that there is an issue in reverse proxy that points to the apache web server when accessing via https in safari ios. It's really weird and i don't know what is really the issue here because when i try to access a normal website that is hosted in IIS along with the reverse proxy, i can access them successfully.
I hope you guys can help me in this issue.
This is the website url: https://www.investagrams.com/daily/ (you can also test them --- try to access in ios safari it would fail, and other browser --- all successful).
I did some research and this happens because iOS 11 is improperly negotiating a HTTP/2 TLS connection and the connection fails. Microsoft has a fully supported workaround, which disables HTTP/2 TLS connections.
More information about the issue can be read here: https://www.essential.exchange/2017/09/18/ios-11-about-to-release-things-to-be-aware-of/
Workaround
Disable HTTP/2 until its fixed by Apple.
To enable or disable HTTP/2, follow these steps:
Start regedit (Registry Editor).
Move to this subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
Set DWORD type value EnableHttp2Tls to one the following:
Set to 0 to disable HTTP/2
Set to 1 to enable HTTP/2
Restart the computer.
Reference: https://support.microsoft.com/en-us/help/4032720/how-to-deploy-custom-cipher-suite-ordering-in-windows-server-2016