Yonke imikhiqizo Community Forum

I already changed the password but I’d be glad to know if there is anything I could do or anything you could tell me about the person who entered my Firefox, the person is apparently from Russia, I’ll attach the image below.

Until some days ago I could use the add on "Video Downloadhelper" without problems on my old Macbook Air (2017) with OS10.15.7 but suddenly the add on was not available anymore. I purchased a valid license for this add on. In the Firefox adjustments it was mentioned as deactivated. Could you please let me know, how I can activate the Video Downloadhelper again? Thanking you in advance for your kind support. Sincerely, Ulf Gaertner

Hello, my password got reset by pour IT department all of my passwords are gone I do have a recovery key but they did not use it how do i get my passwords back where can i add the key code

Hello. i noticed that my shortcuts are missing. i went to settings to check if it's enabled (check mark) and it is in fact enabled. tried to reset my computer and the shortcuts are still not there. on the main firefox page there is actually no shortcut icons on there...at all. all of the options in settings work with the exception (of course) the shortcuts. i would like to know why this is happening...thx

simply that except for the odd ocassion, I cannot download documetns generated by Copilot when i'm using firefox. I uninstalled Firefox and it worked on Edge but for a while and then i started having problems with that as well. For several months when i first started usin Copilot, it worked fine and then suddenly I started having problems.

We run the www.rarlab.com website and several users have complained that the download of the exe file for the English version of WinRAR 7.20 downloads a 0mb file and is also flagged as malicious. The file can be downloaded easily on the Edge browser and it is considered safe by Google too.

Hello everyone,

We are currently investigating an issue where browsers are sending HTTP requests with Connection: close in the header during integrated Windows authentication (NTLM authentication) via SAML Service Provider (SP), leading to premature termination of the TCP connection.

This behavior occurs in the middle of the authentication process, preventing the NTLM authentication from completing and subsequently prompting for re-authentication.

We have observed the following browser behaviors:

Chrome and Edge: These browsers function without issues, communicating with Connection: keep-alive. Safari (macOS): Older versions of macOS with Safari exhibit the Connection: close behavior, leading to authentication failure. Newer versions of macOS with Safari work correctly with Connection: keep-alive. Firefox (macOS): Even on the latest versions of macOS, Firefox continues to attach Connection: close, resulting in authentication failure. Upon reviewing logs, we've identified that various browsers attach the Connection: close header during the NTLMSSP_NEGOTIATE request in the NTLM authentication sequence. Although this happens in an environment with a load balancer, we have confirmed that the load balancer is not modifying the header; rather, the client (browser) is adding it.

We would appreciate your insights into the conditions under which Firefox attaches Connection: close to HTTP requests, especially considering the differences across macOS versions and other browsers, addressing the following points:

Are there any known conditions or past cases where Firefox outputs Connection: close in an NTLM authentication environment via SAML SP? Given that older Safari versions show similar behavior, we are also considering if there's a common factor depending on NTLM authentication and browser version. What are the general heuristics, logic, or triggers for a browser to decide to "close" a connection or to attach Connection: close? We are particularly interested in cases that occur mid-authentication process. Could specific configurations (e.g., the combination of SAML and NTLM authentication, or the presence of an intermediate proxy/load balancer) potentially influence Firefox's Connection: close behavior? Are there any additional logs or debugging information we should collect from the Firefox client side to further pinpoint this issue? Any guidance or suggestions you could provide to help us resolve this problem would be greatly appreciated.

Thank you.