Jenkins defaults to https on Firefox and Chrome but not IE - jenkins

Jenkins was working fine on Firefox until a couple of weeks back.
http://www.sub.domain.com:8080
Then I think there was a Firefox update and by default it was redirecting to
https://www.sub.domain.com:8080
There was no way I could force it to http.
So I went on Chrome and it worked there until this morning when I got the Chrome 77 update.
Same issue all over again.
Then I loaded it up on IE. It works fine. I am able to use
http://www.sub.domain.com:8080
I checked with the admin if they are redirecting all traffic to https but that's not the case. What's happening here? Any browser change that I am not aware of? Any Jenkins config change that I should be using?

Did you check the HSTS cache in chrome? Go to chrome://net-internals/#hsts
Query the HSTS cache there. If there is a result you can clear it using the delete option on that page.
Another thing to check is if your using the Jenkins HSTS filter plugin "which adds a response header indicating that HTTP Strict Transport Security (HSTS) response headers should be sent." See https://wiki.jenkins.io/display/JENKINS/HSTS+Filter+Plugin

Related

apache cache settings to get 200 or 304 as appropriate

I am running Apache 2.4.18 on Ubuntu (single server machine). I didn't make any changes to the default settings as far as cache headers are concerned (no cache-related change to /etc/apache2/apached2.conf, no .htaccess files). My understanding is that apache's default behavior is to use ETag's, with the desired behavior of returning a 304 if the client already has a matching file, or a 200 (plus the new file) if it does not.
This is not what I see.
On iOS/Safari, when I update files on the server, my client behaves as if it has a mix of old and new files. This can be resolved by clearing web data in Safari and reloading the page, so it does seem to be a caching issue. I read that iOS/Safari is (or at least was, in earlier versions?) different in its respect for ETag headers. But it wasn't clear to me how to fix this.
On Chrome in Windows, the file is always served (i.e., response 200, not 304) even when the file hasn't changed since the last request, even though I can see the use of ETag in the headers.
Can someone share their apache 2.4 settings to get the desired behavior I describe above, on both iOS and Chrome?
(Here is another question that asks the same thing about the Chrome part: Apache + Etags -> returns 200 and send content instead of 304)
I think the answer to my question is that caching works differently, at least in Chrome, when you are using the file:// protocol to test locally vs. the http:// protocol.

Moving TFS 2017 from HTTP to HTTPS causes extensions not working properly

I installed TFS 2017 to be accessible on both, HTTP (port 8080, default settings) and HTTPS. Now I removed HTTP binding form the IIS and reapplied the Public URL (via Administration Console -> Change Public URL).
Most of the TFS application tier works normally (as it uses relative addressing). However, build extensions somehow want to get their icons from HTTP (port 8080). See screenshot. When I noticed this, I first checked the HTML/JS source and I found that _vssPageContext variable still holds some URLs pointing to old HTTP configuration.
Has anyone solved that mistery or has any idea what to do?
EDIT: Later I re-enabled the HTTP bindings in IIS just to make the TFS work and I get a lot of warnings and errors due to HTTP / HTTPS mixup (I access TFS via HTTPS, however some content is still accessed via HTTP):
Mixed Content: The page at
'https://xxxx.xxxxx.xxxx/tfs/TFSDefault/Project/_build/definitionEditor?definitionId=113&_a=simple-process'
was loaded over HTTPS, but requested an insecure image
'http://xxxx.xxxxx.xxxx:8080/tfs/TFSDefault/_apis/distributedtask/tasks/9fcb05af-0ffe-4687-99f2-99821aad927e/0.1.1305/icon'.
This content should also be served over HTTPS.
WebSocket connection to
'ws://xxxx.xxxxx.xxxx:8080/tfs/signalr/connect?transport=webSockets&clientProtocol=1.5&contextToken=412c3608-de3b-4dab-a00d-bf5c13728d97&connectionToken=OoSymcl1qzWg%2BrHB9pzSBpb%2BdHVywo7NNUWN5xMx3Z51p9ZdZQ14wvoQKXqxB%2Bvo66eTap4iUdlqzHR1hJNUf%2By8oFUaudlkCbQIZjHQhLBHsEWtcLdfLlL7MAevl4h0My1yQA%3D%3D&connectionData=%5B%7B%22name%22%3A%22builddetailhub%22%7D%5D&tid=7'
failed: HTTP Authentication failed; no valid credentials available.
This is an issue related to the default endpoint of TFS being initially set as http, which all the elements are then defaulting their requests to, rather than relying on the initial request you are making in the browser. so you end up with a javascript element attempting to connect to the server via http and get a cross content issue.
Here is a really good article that covers the issues you are probably facing and how to fix them to use https: https://hybriddbablog.com/2017/12/16/changing-tfs-to-use-https-update-your-agent-settings-too/
I have to caveat that I havent done this yet, we actually went back in favour of running http until we moved to the next version of TFS, but from my experience of TFS, the steps look sound.

The required anti-forgery cookie "__RequestVerificationToken" is not present only in Google Chrome

I have an existing website and suddenly some days ago I can't use Google Chrome anymore for developing. When I use a standard edit and create page, I get the above error. But i'm not getting it in Internet Explorer. I use Windows 10 (all updates installed) and VS2013 with Update 4. The project is the latest MVC version. I even checked the web.config but nothing is changed. I deleted all history, cookies, passwords etc.
Anyone any idea?
I had the same problem. For me the solution was to both clear my browser cookies and to disable Adblock. Other addons may have the same effect. I believe the problem is limited to the Visual Studio / Chrome development environment and will not occur in production regardless of whether the end user has Adblock enabled or not.
Do you have a
<httpCookies requireSSL="true" />
in your Web.config? Change that to false. Then in your transforms files (Web.Prod.config, and other environments that have SSL):
<httpCookies requireSSL="true" xdt:Transform="SetAttributes" />
I'm also having the same issue in recent weeks, but it's also extending cross-browser after originating from Chrome. What's even stranger is that it still works flawlessly with the identical project on a different machine using all browsers.
I have gone so far as to uninstall all extensions, delete all cookies / data, sign out of Chrome completely and re-install it. Problem still persists.
On deployment to Azure websites the problem isn't present on any platform. My current work-around is to Ctrl-F [ValidateAntiForgeryToken] and comment out every occurrence, and re-enable it upon deployment. Annoying, but it works.
This was happening to me in Chrome, and seemed related to using the 'remember me' checkbox on login forms, and closing then re-opening the browser. The token was present on inspecting page source, but was reported as being not present during debugging sessions in visual studio. By clearing the browser cache and not checking the 'remember me' box I did not get the problem - but I don't fully understand why!!
My steps to reproduce the bug in Chrome:
Sign in to your MVC web application, clicking on 'remember me' to make it checked
Close browser
Open browser to your current retained session
Try to sign out - error happens here.
Anyway, the following solution worked for me. Inside your MVC view form, try replacing this:
#Html.AntiForgeryToken()
with:
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
Are you on cloud platform ? chrome emits cookies from cloud domains hence the only way to do it is to map another named domain to your cloud web site
This is probably because browsers like Chrome use the Public Suffix List(https://publicsuffix.org/list/effective_tld_names.dat) to restrict certain cookies. If the domain suffix set on the cookie is shared publicly then the browser may block such a cookie in order to prevent itself from sending "unauthorized" data to other servers running on the same domain.

website is redirected to "https" in firefox(it is normal in other browser)

I am open my website in firefox, but because of something wrong with my website, url is force redirected to https(I think this is because I write config.force_ssl = true in ruby on rails application).
But after I redeploy another ruby on rails application, firefox still force redirect to https, how can I make firefox do not redirect to https?
This is a browser caching issue.
Rails redirects to the HTTPS site using HTTP Status 301 (moved permanentely), the redirect is cached by Firefox.
Because the Host is always localhost, Firefox cannot differentiate between the individual Rails applications.
To resolve this problem try emptying the cache and/or use private browsing mode for testing.
I don't know about Firefox but in Chrome there's the option to completely deactivate caching for as long the dev tools are open.
Try to clear the cache. Firefox may remember http 302 - redirect permanently, and it does not know when you are using different rails application (as you probably run both on localhost:3000).

MVC WebApplication no longer starts in IIS Express (redirects to https://localhost in Chrome)

I was changing OAuth/Owin settings and Azure publish settings in a Web Application project this morning, but soon after we decided deployment will be to a specific IIS Azure VM (now visible across our local domain). All code/setting changes have been reverted.
At one point I also changed the drivers\etc\hosts file to allow a dummy name for Microsoft OAuth, but that has been reverted.
Notes:
My startup URL is http://localhost:22222/
I am running under IIS Express (as my local Dev VM will not allow me to install full IIS)
When I start the Web Application with IE I simply get "This page can't be displayed"
If I start it with Chrome I get "This webpage is not available", but it also changes the browser URL to https://localhost (note the s, i.e. using SSL).
I have pulled the project down fresh from source control. No change.
The project is under TFS source control.
Another developer on the same project has the latest files and it works fine.
If I run any other Web Application project, they work just fine.
All OWIN registration of providers has been commented out. No change.
Deleted the entire project folder and pulled fresh from TFS. No change. This probably means a local machine setting somewhere is the cause?
What could I have damaged in my Web Application to cause this problem? I have been scratching my head for hours now and nothing we try is working. The application simply will not start in any browser.
Project Web Settings tab:
Answer at bottom, given to this chromium issue [issue 444479] helped me:
Same here - I also believe caused by HSTS - see
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
If you have (developed) any other localhost sites which send a HSTS
header...
eg. Strict-Transport-Security: max-age=31536000; includeSubDomains;
preload
...then depending on the value of max-age, future requests to
localhost will be required to be served over HTTPS.
To get around this, I did the following.
In the Chrome address bar type "chrome://net-internals/#hsts"
At the very bottom of a page is QUERY domain textbox - verify that localhost is known to the browser
If it is, DELETE the localhost domain using the textbox above
Your site should now work using plain old HTTP
HTH,
Jay
ps. This is not a permanent solution, but will at least get it working
between projects. If anyone knows how to permanently exclude localhost
from the HSTS list please let me know :)
Give it a try.

Resources