Open Bug 1710761 Opened 3 years ago Updated 2 months ago

Can't log in to citi.com most of the time.

Categories

(Web Compatibility :: Site Reports, defect, P1)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 93
Platform:
x86_64
Windows 10
Type:
defect

Tracking

(firefox90 unaffected, firefox91 unaffected, firefox92 affected, firefox93 affected)

Tracking Flags:
Tracking Status
firefox90 --- unaffected
firefox91 --- unaffected
firefox92 --- affected
firefox93 --- affected

People

(Reporter: streetwolf52, Unassigned)

References

Details

(Keywords: webcompat:needs-contact, Whiteboard: [webcompat:needs-login])

Attachments

(3 files)

console-export-2021-5-11_20-17-26.zip
8.67 KB, application/x-zip-compressed
Details
Console log under Fx91 beta.
98.40 KB, application/x-zip-compressed
Details
Log file from using shift-Ctrl-J
12.87 KB, application/x-zip-compressed
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Go to citi.com.
Sign in with userid/password.

Actual results:

Spinner appears for a few seconds and then thrown back to the sign in screen.

Expected results:

Should have been logged in.

Sign in works on Fx 88.1 and MS Edge Chrome.
I've had this happen a few weeks ago but it cleared up. The current situation started with the past few Nightlies.

I've attached my Browser Console Log.

Forgot to mention that this problem also happens with a brand new profile and in safe mode.

Using Fx88.1 there are a few inconsequential console messages. When running with Nightly the console log is continually filling up with all sorts of messages even before I sign in.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Password Manager
Product: Firefox → Toolkit

I don't think that this belongs to Toolkit:Password Manager. I have it disabled. I use an add-on to manage my passwords. It's not this add-on causing the problem as I still get the issue with a new Profile which does not have my add on.

Component: Password Manager → Untriaged
OS: Unspecified → Windows 10
Product: Toolkit → Firefox
Hardware: Unspecified → x86_64

Apart from the file I attached is there any thing else I can provide you in order to get to the bottom of my problem?

Hey Gary,
Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Flags: needinfo?(garyshap)

The sign on started working again sometime yesterday. I don't think it was a Nightly update that caused it to start working. I've had this same situation happen the last time it stopped working. After a period of time things got back to normal too. No telling if it will stop working again.

I did try safe mode and a new profile with no add-ons or customizations before it started working on it's own yesterday. I use Nightly and that was the only version of Fx I found to have the problem until yesterday.

As mentioned I wouldn't be surprised if the problem happens again. I'll leave it up to you whether to close this report or keep it open for a little while longer.

Flags: needinfo?(garyshap)

Didn't take long. I can't sign on once more. Fx88 and MS Edge work fine. I even changed my password to no avail.

I noticed that this time I get a message asking if I forgot my userid or password. I changed my password but that didn't work. Again, things work fine on Fx88 and MS Edge with my new password.

Things are working again. I don't understand what is happening. Fx88 and MS Edge always worked. I never got the same works/doesn't work/works situation with those.

Cached files or cookies? Proxy cache? Testing on their end?

If it's something on their end why are Fx88 and MS Edge working just fine all the time? Running Nightly with a new profile takes care of cookies and cache considerations. Luckily when things aren't working on Nightly I have other options.

Can't sign on again. Something is not right with Nightly at citi.com.

I am seeing the same issue on the following banking sites.
https://www.digitalbanking.rbs.co.uk/Default.aspx
https://onlinebanking.nationwide.co.uk/AccessManagement/Login

It seems to be cookie related, as the console is filled with various cookie errors, similar to these:

Cookie “cdContextId” has been rejected for invalid domain.
Cookie “cdSNum” has been rejected for invalid domain.
Cookie “” has been rejected as third-party.
Cookie “” has been rejected as third-party.
Some cookies are misusing the “SameSite“ attribute, so it won’t work as expected 75

I'm also having sign in problems at santander.com at times. In this case I am asked to verify who I am via a text message code. Clearing cookies for the site temporarily stops this but it will come back eventually.

It appears my problem at Santander.com is a site problem as other browsers also require further authentication.

I worked out the problem with both the following sites.
https://www.digitalbanking.rbs.co.uk/Default.aspx
https://onlinebanking.nationwide.co.uk/AccessManagement/Login

It seems that they recently did some updates and it changed the referrer information. I have an extension that blocks the sending of unknown referrers and this caused both sites to fail.

Once I whitelisted the referrers, both sites started working again.

Gary can you try Soothsayer's solutions and get back to us if it's working?

Flags: needinfo?(garyshap)

Soothsayer's problem was completely different than mine. That being said I have not had the problem for about 2 weeks. This is not to say the problem won't crop up again as it did so in the past. You get the impression that the problem was a site issue but why did every other browser except Nightly work each and every time? My guess is that Nightly with it's daily changes triggered the problem on and off by some changes. Hopefully the problem won't come back.

If you want to close this report that is fine with me. If the problem comes back I don't know what steps would be needed to investigate it by Mozilla.

Flags: needinfo?(garyshap)

The problem has raised it's ugly head again. When I login it gives me a message that my userid and/or password might be incorrect. I successfully logged in using Fx89 and MS Edge using the same credentials. The last time I was able to login on Nightly was yesterday. How do I investigate this problem? I am hesitant to give you my userid and password for you to log in.

Still can't login using a new Profile or in safe mode.

This issue is still occurring. I am able to log into the site consistently using both Fx91.0b7 and Fx90 as well as MS Edge and Google Chrome. At times I am able to log on under Fx Nightly. It might last a day or so. Currently I haven't been able to log on under Nightly for over two days while all the other browsers I mentioned let me log in.

I tried a new profile with no add-ons or other changes. I still can't log on at this moment. Please investigate this. I previously provided my browser logs. Perhaps you know of a preference that might be causing this?

Isn't anyone going to look into this? I'll help as much as I can short of allowing access to my Citi account.

What is it going to take to at least get an acknowledgement about my problem? It is annoying to have to use another browser to log on to my Citi account when Nightly refuses to process my log in credentials properly.

status-firefox90: affected → unaffected
status-firefox91: affected → unaffected
Component: Untriaged → Networking
Priority: -- → P2
Product: Firefox → Core
Version: Firefox 90 → Firefox 92

Since you said this works before, could you try to use mozregression to find out the problem? I think this is the fastest way to help us debug this.

Thanks.

Flags: needinfo?(garyshap)

It hasn't worked properly on Nightly going back to 90 I believe. It would be near impossible to track down a regression going back that far. As I said the current non-Nightly versions of Fx (up to 91) work fine as well as Edge and Google Chrome. Keep in mind that it sometimes works fine on Nightly too. I might get anywhere from 1/2 a day to a full day of my logins working. Eventually the login will fail again. I'd say 90% of the time it fails. All the other browsers never failed on me. It appears my login credentials are not be passed which is why I get a message from the site asking if I might have forgotten my userid and/or password.

I supplied my browser console log file earlier on. Don't they give you some indication on what is occurring? Getting a regression range is not an option for me as it would take up too much of my time.

Flags: needinfo?(garyshap)

Reset the priority to make sure this bug can be triaged properly.

Component: Networking → Networking: Cookies
Priority: P2 → --

(In reply to Kershaw Chang [:kershaw] from comment #27)

Reset the priority to make sure this bug can be triaged properly.

I only set the priority to get someone to look into this. It apparently worked. Now that is set to triage again it might linger in limbo once more.

Console log output under Fx91 beta which works fine. Might be useful as a comparison to the failing console log.

Summary: Can't login to citi.com. → Can't log in to citi.com most of the time.
Version: Firefox 92 → Firefox 93

(In reply to Gary [:streetwolf52] from comment #28)

(In reply to Kershaw Chang [:kershaw] from comment #27)

Reset the priority to make sure this bug can be triaged properly.

I only set the priority to get someone to look into this. It apparently worked. Now that is set to triage again it might linger in limbo once more.

The bugs without priority are looked at within a day or two. Please do not set priority and let us triage bugs.

My apologies, I just notice that this bug was very long in "Untriaged" component. That should have changed faster.

Hi Gary,

Given that this only seems to happen on Nightly (if I read all the previous comments correctly) this is caused by one of the settings that we only enable on Nightly.

One of the next prefs will probably fix the website for you.

network.cookie.sameSite.laxByDefault
network.cookie.sameSite.noneRequiresSecure
network.cookie.sameSite.schemeful

Could you do the following? Go to about:config. For each of the prefs, set it to false, go to the website and see if it works.
When it finally works, we'll know which one was to blame. Please let us know if this fixes the problem. Thanks!

Flags: needinfo?(garyshap)

I already tried that by setting the same prefs to false in the Nightly Experiments. However I just did it via about:config. I still get the logon error. As mentioned before, on occasion I can logon. Yesterday was such a day. Today I can't logon. Perhaps the site is doing something wacky at times that Nightly can't handle whereas all other versions of Fx can. Same goes for Google Chrome and Edge.

I would love to find the regression but as I noted I would have to go back so far it would take too much of my time to find it. The only possible way of finding a regression, or at least narrowing it down a bit, is to find where previous versions of Nightly are stored in ZIP format. I can then start downloading past versions and update my Nightly folder with it and start tracking down the last good version by trial and error.

I recall accessing such a site that had previous Nightly's arranged by date and time but I can't remember where they were. Perhaps you can direct me to them.

Flags: needinfo?(garyshap)

I just took a look at attachment 9221461 [details] and saw things like this:

XHRPOSThttps://contents2.00110.citi.com/client/v3.1/web/wup?cid=cedric
Blocked By Extension

It's not clear which extension is causing this.
I'm wondering if this is maybe caused by multiple issues?
Try disabling the prefs in a new profile with Nightly.

If it still happens, you can try using the mozregression tool:
https://mozilla.github.io/mozregression/install.html
mozregression --repo=mozilla-central -g 2018-01-01

This command should allow you to find the time when the issue started happening on Nightly.

Flags: needinfo?(garyshap)

Using a new profile there are no added extensions. I do believe there are some default ones which comes with Fx like the screenshot extension. I think it's under Features. Perhaps I can delete these and see what happens. I'll try a new profile and set the prefs to false.

Flags: needinfo?(garyshap)

I fired up Nightly with a new profile and insured the 3 prefs were set to False. Still can't log on. I then copied prefs.js from Fx92 which works fine and replaced the one in my new clean Nightly thinking another pref might be the cause. Still can't log on.

There are some nightly-only prefs that are defined in the binary.
I've split them into 2 categories - first one is likely to have an effect. Later ones probably won't. If you try to flip them do it in a new profile.
Thanks!

network.cookie.sameSite.laxByDefault
network.cookie.sameSite.noneRequiresSecure
network.cookie.sameSite.schemeful
network.ssl_tokens_cache_enabled
network.dns.force_waiting_https_rr
privacy.trackingprotection.origin_telemetry.enabled
privacy.trackingprotection.lower_network_priority
privacy.partition.bloburl_per_agent_cluster
browser.opaqueResponseBlocking

widget.non-native-theme.webrender
apz.record_checkerboarding
dom.dialog_element.enabled
dom.event.treat_ctrl_click_as_right_click.disabled
dom.forms.autocapitalize
dom.forms.enterkeyhint
dom.reporting.enabled
dom.reporting.featurePolicy.enabled
dom.select_events.textcontrols.selectstart.enabled
dom.w3c_pointer_events.dispatch_by_pointer_messages
dom.webcomponents.formAssociatedCustomElement.enabled
dom.webnotifications.requireinteraction.enabled
javascript.options.wasm_moz_intgemm
javascript.options.wasm_extended_const
layout.animation.prerender.partial
layout.css.color-mix.enabled
layout.css.color-mix.color-spaces.enabled
layout.css.d-property.enabled
layout.css.grid-template-masonry-value.enabled
layout.css.motion-path-ray.enabled
layout.css.math-style.enabled
mathml.mathspace_names.disabled
mathml.scriptminsize_attribute.disabled
mathml.scriptsizemultiplier_attribute.disabled
media.mediacapabilities.from-database
media.allowed-to-play.enabled
security.sandbox.rdd.shadow-stack.enabled
security.sandbox.socket.shadow-stack.enabled

I ran mozregression-gui and the first Nightly version that failed is as follows:

app_name: firefox
build_date: 2020-01-12
build_file: C:\Users\Gary Shapiro.mozilla\mozregression\persist\2020-01-12--mozilla-central--firefox-74.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2020/01/2020-01-12-21-45-46-mozilla-central/firefox-74.0a1.en-US.win64.zip
changeset: 1536cf66a302811c1e302118e0d356c6c7545fab
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

I am really surprised it went back this far. I don;t recall having my problem for so long. Perhaps it was fixed at some point and then it was reintroduced at a later date.

Could you run mozregression until it finishes?
At the end it will give you a regression range, with all of the suspected bugs. It's possible the failure started even earlier.

Flags: needinfo?(garyshap)

As mentioned I am using mozregression-gui. I am probably not entering in some things that will give me the regression range. Can you tell me what I should place in the various fields?

If the command line mozregression you mentioned is the way to go where exactly can I find the executable? All I see at https://mozilla.github.io/mozregression/install.html is some Python program.

Flags: needinfo?(garyshap)

After each step when you say if the build is good or not, in the output window you'll see a pushlog URL:
Check out the video here: https://mozilla.github.io/mozregression/quickstart.html

I ran a bisect and it came up with an error message:

End of the bisection

Unable to find enough data to bisect.

OK

The date range I gave was 01/11/2020 to 01/12/2020. Doesn't seem there would be to much date for one or two days. Am I correct that the dates are in American format?

The video uses an older version. The newest version has more options. Anyway I think I might have gotten what you needed. Remember the failing date is 2020-01-12 which in America is 01/12/2020 and NOT 12/01/2020. I the dates are in European format I would be getting a months worth of data 11/01 - 12/01.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e6427fac5ee8d1d87fb78e917781e85dda119a81&tochange=1536cf66a302811c1e302118e0d356c6c7545fab

As of this moment I am able to log on to my Citi account. I changed nothing to cause this. Rest assured that at some point today or tomorrow I probably won't be able to logon again.

Once again I can't logon to citi.com.

status-firefox93: --- → affected

citi.com is working again. I did make a change in my BIOS. I disabled Secure Boot. I had it enabled because Windows 11 seems to require it from what I've been reading. Right after I made this change citi.com started to accept my login. Since the login would suddenly work at times regardless I don't know if it would have worked even if I left Secure Boot enabled. Only time will tell if Secure Boot was the culprit. I'll report back after a few days if citi.com is still working normally or not.

If Secure Boot is the problem and if Windows 11 requires Secure Boot to be enabled will you take any action to insure everything works fine under Fx?

Can't login again. Rule disabling Secure Boot out of the equation.

(In reply to Gary [:streetwolf52] from comment #43)

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e6427fac5ee8d1d87fb78e917781e85dda119a81&tochange=1536cf66a302811c1e302118e0d356c6c7545fab

My best guess for the cause of this is bug 1472158.

Could you check if setting privacy.partition.bloburl_per_agent_cluster to false in about:config changes things for you?
Thanks!

Flags: needinfo?(garyshap)

Setting the pref to False didn't work.

I find it odd that I had to go way back to Fx74 Nightly to find a regression. I would think that whatever brokes citi.com would have made it to the stable version as well as the latest beta version. Perhaps I have a misunderstanding of the way patches progress up the release latter.

Of course there could have been a series of patches that broke/fixed citi.com. If so there could be regressions further up the line to the current Fx Nightly.

The only saving grace to all of this is that I can use the stable version and even the beta version to always login to citi.com. Also as mentioned login works every now and then on Nightly

Flags: needinfo?(garyshap)

There are some features and prefs that are nightly only.
Looking at this, it seems there are also some prefs that are "early beta or earlier":
network.http.referer.disallowCrossSiteRelaxingDefault
privacy.annotate_channels.strict_list.enabled
network.dns.use_https_rr_as_altsvc
signon.usernameOnlyForm.enabled
dom.webshare.enabled
layout.dynamic-reflow-roots.enabled
media.av1.enabled
network.process.enabled
network.jar.record_failure_reason
network.cache.frecency_array_check_enabled

You might want to flip some of these as well, and see if it helps in any way.
I'm sorry it's taking so long to diagnose this issue. Thanks for all your feedback and patience!

Zeroing in on prefs bothers me as I can login to citi at random times. Unless a Nightly only pref randomly changes or changes the way it functions I don't see a pref causing the issue. One might expect not to be able to login all the time.

Seeing that Fx 92 Beta works fine is there a module in the executable folder that contains all the built in prefs? I'm thinking I could copy the folder over to Nightly so that it overrides any new or changed prefs in Nightly. Fx92 beta is probably the most compatible version with Nightly.

IN the meantime I'll experiment with the prefs you mentioned above. I'll flip them.

I flipped all the prefs you gave me. All were defaulted to True in Nightly so they all became False. Still can't login to Citi.

Just checked Fx92b4 and all the prefs you mentioned are also set to True. Fx93b4 works fine at citi.com.

Citi is once again working until it doesn't. I really don't understand what is causing it to work sometimes and then not work. There are no changes to Fx that I actively make. My thoughts on this behavior could be that the site every so often does something different that Nightly can't handle properly.

I took a look at my Browser Log on Nightly where I can't log in. I see this entry:
Protocol version: "TLSv1.2"

When I run Fx91 where I can always log in I see this in my Browser Log:
Protocol version: "TLSv1.3"

Could TLS v1.2 be the cause? When things are working again under Nightly I'll check the TLS version to see if it changes unless you think I am researching a dead end.

Just ran Fx92b4 which works and it shows TLSv1.2 so I guess I was wrong.

Out of curiosity, is the issue reproducible on Nightly on a different machine, on same and different networks? Is the issue reproducible for multiple Citi accounts or just one?

Flags: needinfo?(garyshap)

I can check it out on a different machine but I would have to use someone else's network to see if it's my network causing the problem.

I do have an update for you. I have done lots of testing of various things to try and narrow it down. In the past in order to prevent so called super cookies from being recorded in SiteSecurityServiceState.txt I marked it as read only. I did this for privacy reasons. Yesterday I took away the read only attribute. Citi started working but I don't recall if it was already working as it does every so often. It's been over 24 hours and I've been logging in with no issues ever since. I never went this long with a log in failure.

Looking at the file there are lots of entries for citi.com. The only 'fly in the ointment' is that when I test with a new Profile the file does not have the read-only attribute turned on yet the log in fails. It's possible that I am in a much longer period of time where the site is working. Of course something else might have changed that I am not aware of.

Do you have any info on whether making SiteSecurityServiceState.txt read-only can cause my problem?

Flags: needinfo?(garyshap)

Some more good news. I created another new profile and citi worked fine. In the past my log in would fail the first and subsequent times on a new profile. So now I am thinking that SiteSecurityServiceState.txt might not be the problem. Perhaps an update within the Fx executable folder made it work or something else. So far all of this is good news. Now only time will tell.

I went about 2 days with no problem logging in. I thought that something might have fixed my problem. Then yesterday for about a 2 hour period I couldn't log in again. After that I could log in. This morning I was still able to login until about an hour ago when I can't once more.

Seeing as I don't have this issue with any other browser or version of FX other than Nightly I can't see how it's network related unless Nightly among all browsers doesn't like my network and only sometimes. Tried on my laptop with the same results as my desktop.

If you want I'd let you on my machine remotely when I am having the issue like I am now. I usually use TeamViewer but I suppose you guys probably have a similar product you use.

All I can think of is asking for a http log when the login failed.
Note that the log may contain your cookies, so please send the log to my email address. Thanks.

Flags: needinfo?(garyshap)

Citi has been working and not working the past day or so. There is an entry in the log when it is failing that says that there were too many attempts to login I presume which is not true. The error I get from citi is not the same one I get if I supply an invalid username and/or PW.

There is an entry that has some good info in it. The only thing it has about 6 tabs associated with it. Is there a file that contains the log in it's raw form that I can send you so that you might see all the messages as I do. Saving the log doesn't show these tabs. If not I would have to open up each tab and take a screen shot.

Flags: needinfo?(garyshap)

(In reply to Gary [:streetwolf52] from comment #62)

Citi has been working and not working the past day or so. There is an entry in the log when it is failing that says that there were too many attempts to login I presume which is not true. The error I get from citi is not the same one I get if I supply an invalid username and/or PW.

There is an entry that has some good info in it. The only thing it has about 6 tabs associated with it. Is there a file that contains the log in it's raw form that I can send you so that you might see all the messages as I do. Saving the log doesn't show these tabs. If not I would have to open up each tab and take a screen shot.

Please take a look at this: https://firefox-source-docs.mozilla.org/networking/http/logging.html.
This is the log we need to analyze. Thanks.

Flags: needinfo?(garyshap)

At the moment citi is working. As soon as it stops working I'll get the log you need.

Flags: needinfo?(garyshap)

Attached is the log you requested when logging into citi.com fails. You might want to search for [HTTP/1.1 429 Too Many Requests] in the log. I get a lot of these when the log in fails. There are probably other things to look for.

The site seems to constantly write log records even if I do nothing on the site. This accounts for the large number of records I suspect.

Apart from the 429 response, I can't find any thing wrong from the log. I was wondering whether other browsers also get this response.
Could you check some things below:

  1. Do you also see 429 response when the login succeed?
  2. Since 429 indicates that the server is busy, are you able to login after a while (don't close Firefox and perhaps wait for 10mins)?
  3. Do you use VPN or something? Could you try to change your IP immediately after getting 429 response and try again?
  4. I think it's unlikely that server thinks that there are too many connections created from Fierfox, but you could try to adjust the value in network.http.max-persistent-connections-per-server and network.http.max-urgent-start-excessive-connections-per-host and see if it helps.

Thanks.

Flags: needinfo?(garyshap)

Hoping the log file I captured this way has some more useful information for you. The interesting entry in the log has 6 tabs on it so I had to save the log six times which each tab open. Go to the line that says 'Too Many Requests' for all 6 files. There might be more info than the big log I sent you.

Other versions of Fx which always work do not show error 429.

I upped the value of the two prefs you gave me. It didn't help.

I submitted logs when I first opened this report. The on with Fx91 beta worked and has no 429 error. The other one was produced on a failing Nightly.

Flags: needinfo?(garyshap)

(In reply to Gary [:streetwolf52] from comment #67)

Other versions of Fx which always work do not show error 429.

That's weird. I really have no idea why the server returns 429.

I upped the value of the two prefs you gave me. It didn't help.

Sorry, I was not precise about this two prefs. What I'd like to know is if it would work if we open less connections. So, please try to set network.http.max-urgent-start-excessive-connections-per-host to 0 and network.http.max-persistent-connections-per-server to 3.

I submitted logs when I first opened this report. The on with Fx91 beta worked and has no 429 error. The other one was produced on a failing Nightly.

What about using another IP address to connect? Does it help?

Flags: needinfo?(garyshap)

I used my VPN to connect me with different servers with different IP's. Still can't log in.

The situation in a nutshell is this:

  1. Every single browser no matter the brand works all the time except for Nightly.

  2. Even though my regression hunt pointed to version 74 as it starting I can't remember it working this way back then. This might indicate that citi did something way after 74 that finally affected Nightly from 74 onward. In other words it's possible that even though things don't work now from 74 thru 93 it probably worked when 74+ was the current version and citi didn't make it's presumed change. But why the randomness?

This randomness really clouds the issue. What is it about Nightly that most of the time does not play nicely with citi.com? Is citi doing things differently at times that Nightly can't handle? I'd like to solve my problem but I can always use another version of Fx or another browser to login.

Flags: needinfo?(garyshap)

Citi has been working fine for almost 24 hours. I created a log file during this time. Perhaps if you compare it to the log file I gave you yesterday when it wasn't working you can pinpoint the problem. Here's a link to it because it is too large to attach it to this bug report.

https://1drv.ms/u/s!AtusZi2hwX-rhJwHeUOGKu6ImP0bpw?e=1k8iov

I notice that when my login is failing just going to citi.com without even logging on my console log constantly fills up with requests. When the login is working this does not happen. Could it be all these seemingly never ending requests are causing the 429 error? The requests are cross-origin in nature. You probably have them in the documentation I sent you.

You might be able to see the problem by just going to citi.com and checking your console log. The latest version of Nightly is needed. I am running Windows 10 so unless the problem also happens on other OS's stick with Windows 10. Keep in mind that the site will work at times. The give away for you is seeing all the requests being generated since you probably don't have a login ID for citi. If there is very little activity in the log that would indicate that a login is possible at that time. As of right now I can't login. Before this I went over 24 hours with no problems.

Here's the message I am receiving just going to the site:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://prod.report.nacustomerexperience.citi.com/glassbox/reporting/cls_report?clsjsv=6.3.126B13&_cls_s=da0335eb-2422-44d5-9784-3607e05693ee:1&_cls_v=341ad289-4db9-42df-9d93-26dee4cb70f3&pid=b8d58f39-0e6a-4b27-bab1-ab59b6c9013c&sn=1&cfg=17dbce73&pv=2&aid=. (Reason: CORS request did not succeed).

I installed Nightly on a vanilla Windows 10 VM. I can't login and I get the same 429 error. The big difference is that I don't constantly get the log entries I mentioned. I think I only got one. Basically the logging will stop after I get the login error message.

I tried with a new profile on my production machine. I got the same sort of log like I did on my VM. One 429 message and the log wasn't flooded with other messages. It might be an add-on that is causing the flood of messages in the log. However I still can't login.

IMO I think the problem lies in the Too many requests 429 error. From what I read a site might prevent access to it if it is flooded with too many requests. The only browser version that gets 429 messages is Nightly. You might be able to get the 429 my simply going to citi.com, enter any userid and password and signin. it might take a few tries to get the 429. Is the site locking me out because it perceives I am flooding it with too many requests? Does the site reset itself after some period of time when I haven't visited the site?

If I do the same thing with any other version of Fx or any other browser I never get a 429 message.

I am making an assumption, which might be wrong, that the 'Too many requests' 429 error is the cause of my logon problems. My thinking is that Nightly, unlike every other browser and version of Fx, is flooding citi.com with requests which results in citi thinking it is some sort of attach and temporarily does not allowig me to logon. After some period of time I can finally logon until the flood begins again. This can be an hour or more than a day. It might even be cumulative.

In order for this to happen citi needs to know who I am. I tried to prevent citi from knowing my identity in various ways.

  1. Ran under a VPN with many different IP address.
  2. Spoofed my UserAgent.
  3. Spoofed my MAC.
  4. Deleted all cookies and cache.
  5. Ran with a new Fx profile which takes care of #4 as well as any other files that store my identity.

(In reply to Gary [:streetwolf52] from comment #70)

Citi has been working fine for almost 24 hours. I created a log file during this time. Perhaps if you compare it to the log file I gave you yesterday when it wasn't working you can pinpoint the problem. Here's a link to it because it is too large to attach it to this bug report.

https://1drv.ms/u/s!AtusZi2hwX-rhJwHeUOGKu6ImP0bpw?e=1k8iov

One difference that I noticed from this log is that DoH is enabled and the other is not. Maybe this is the reason. You could try to always enable DoH and see if this still happens.

In summary, I can't find out any networking problem from the log. I can't find the evidence that Firefox sends too many requests to the server, so I don't know why the server returns 429. I'll let this bug stay in the triage queue for a while and let the next one decide what to do.

I decided to ditch Nightly and run with the Beta version. Everything works fine on Beta. I've given you just about everything you requested and I could think of. The DoH issue is not a factor as I tried it enabled and disabled. Feel free to continue investigating on your own if you want to, otherwise mark this bug however you feel fit. Perhaps in the future Beta will inherit whatever is causing my citi.com problem in which case as Arnold said, "I'll be back". Thanks for taking some time out of your busy schedule to look into this.

I decide to change the component to Web Compatibility and see if some one can reach citi.com to figure out why the server returns 429 Too Many Requests.

Component: Networking: Cookies → Desktop
Product: Core → Web Compatibility
See Also: → 1731393

Unfortunately this requires a banking account.

Gary does it still occur for you with the latest Firefox Nightly version?
Karl can we find someone at citi.com to point this out?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(kdubost)
Flags: needinfo?(garyshap)

Sorry for not getting back to you in a more timely manner. I had to stop using Nightly as it started breaking too many things for me. I am currently on the beta channel and Citi.com works fine.

I have no plans to return to Nightly so do what you think is necessary regarding the status of this bug report.

Flags: needinfo?(garyshap)

so that's an interesting issue because if it's happening on nightly and not on beta, there might be a regression.

Another possibility is that the nightly profile which was used was configured with specific settings.
Gary, if with nightly, you could go type about:profiles in the URL bar, then create a new profile and just access the bank, does it reproduce?

Flags: needinfo?(kdubost)
Flags: needinfo?(garyshap)

When I get some time I'll install Nightly and give citi another try.

Flags: needinfo?(garyshap)

Gary did you have the time to install Nightly and see if it works now?

Flags: needinfo?(garyshap)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:denschub, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(garyshap) → needinfo?(dschubert)

There isn't much we can do here without active involvement from the (now inactive) reporter. However, we've seen quite a few reports about it - I was able to find 33 WebCompat bugs with citi.com in the title just now. I'll ask internally if we have someone with an account there.

Flags: needinfo?(dschubert)

Are there any updates regarding this issue?

Flags: needinfo?(dschubert)

(In reply to Dennis Schubert [:denschub] from comment #87)

There isn't much we can do here without active involvement from the (now inactive) reporter. However, we've seen quite a few reports about it - I was able to find 33 WebCompat bugs with citi.com in the title just now. I'll ask internally if we have someone with an account there.

What were your findings on this?

Re-tested the issue bun can not test since a valid account is needed.

Severity: -- → S2
Flags: needinfo?(dschubert)
Keywords: webcompat:needs-contact
Priority: -- → P1
Whiteboard: [webcompat:needs-login]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: