Portal giving Bad Request error again

[VasilMichev]

Can you guys please fix this once and for all? The issue appears every few months, is it that hard to remember to check for cookie lenght? 🙂

This time it seems to be the s.LoginContext one, as well as the s.BECContext. RPSSecAuth is quite large as well.

Can't remember who was responsible for this, so lets try @Anne Michels 🙂

[#2]

Hi Vasil,

thanks for flagging. Could you please submit this through the feedback button in the admin center on the page this happened? That way, the engineering team can more easily connect this with the right logs and investigate.

Thanks,

Anne

[#3]

Aaaaaaaaaaaaaand yet another one, MicrosoftApplicationsTelemetryDeviceId. Getting tired of this...

[#4]

I see this kind of thing in Chrome more than IE. But it's a pain in the ass and the engineering team needs to get a handle on why so many cookies are used and how these cookies cause things to break.

[#5]

I sometimes get redirect to https://www.office.com/landing with a generic browser site not available error. After a page refresh everything works fine again.

[#6]

I used to experience that error a lot, and had to configure Chrome to clear cookes for a couple of O365/MSOnline URLs at close so that the problem wouldn't keep occuring (would happen for OWA, Portal, here on the Tech Community as well). Of course that also meant constantly logging back into things. For the last month or two I've had the cookie removal rules disabled and it's been fine for me.

[#7]

That's what I'm trying to avoid though, all those nasty MFA logins 🙂 And it's about time they learn to properly code those cookies!

[#8]

And here's another example on the same issue from Answers: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin-mso_manage/admin-panel-issue-b...

And an example of how aggravated I'm getting with it 🙂

[#9]

Hi all,

good news: the engineering team is already working on this. We have a fix going on that will adress this issue for the majority of customers. We still expect some customers to see issues for a little while longer as we reduce more cookies. But we're actively working on this.

Thanks,

Anne

[#10]

Good news. Thanks for the update.

[#11]

Thanks Anne. Can you please make sure that the same issue doesnt happen in the future? I mean it's like the 5th time I alone have reported this, then you guys fix it and few weeks later another stupendously large cookie get introduced...

[#12 · Accepted solution]

Hi Vasil,

we're actively working on that. Please keep the feedback coming!

thanks,

Anne

[#13]

At last - been struggling with this for over a year. As a partner, I often get issues by logging in with a tenant id and being prompted (or worse, automatically logged into)a different tenants information. Incredibly inconvenient and a huge security issue that Microsoft seem to think is not their problem in my previous dealings with them.
I found that creating a chrome user profile for each tenant and launching chrome in that user profile fixes the wrong tenant problems and I don't get cookie issues.

Ideally I wanted a script that would just nuke the relevant cookies in chrome, but I was not able to work out how to do this from the command line. Doing it in the gui is several clicks and time consuming when I have to do it 15-20 times a day.

[#14]

Thanks for flagging again, Vasil. I've shared your feedback with our engineering team and they are looking into it.

Thanks,

Anne

[#15]

Um? @Anne Michels that's an old thread, this issue hasnt happened recently and I believe it to be fixed now 🙂

We did have a short outage in parts of EMEA earlier today, but I cried about that in another thread.

[#16]

How wierd! This landed in my inbox today. But good if it's been resolved!

[#17]

Two years later this is still an issue with delve.. we have a custom application which has a 'view users profile' link. Intermittently we get this issue and it affects everyone in the org at different times so it's not a reasonable work around to clear cookies on a case by case basis.

Can the service just be reconfigured to have a less aggressive cap on cookie length?

[#18]

+1 still a problem with viewing profiles on delve. This affects everyone in our org at different times. Not a great experience. We're building something that we sell to our customers and it doesnt look good on us that making apps that work with your APIs only work some of the time and is out of our control..

[#19]

This is still an issue for me. It's been happening for years, and is still frustrating.

Across .office.com and portal.office.com, today I had over 16KB of cookies! This is really extreme. Here are just the ones 50 bytes or over:

Name	Domain	Expires / Max-Age	Size
s.BecContext	portal.office.com	1969-12-31T23:59:59.000Z	4028
OIDCAuthCookie	portal.office.com	1969-12-31T23:59:59.000Z	2938
RPSSecAuth	.office.com	1969-12-31T23:59:59.000Z	2728
AADAuth	.office.com	2019-01-02T07:34:07.931Z	1685
RPSClearCT	.office.com	1969-12-31T23:59:59.000Z	846
AADAuthCode	.office.com	2019-01-02T07:34:07.931Z	686
RPSAuth	.office.com	1969-12-31T23:59:59.000Z	525
(some kind of ID)%40AdobeOrg	.office.com	2020-07-02T09:20:32.000Z	368
msresearch	.office.com	2028-02-12T12:56:56.000Z	345
optimizelySegments	.office.com	2019-08-03T07:53:53.000Z	342
UserIndex	portal.office.com	2018-10-31T08:11:33.372Z	205
s.LoginUserTenantId	portal.office.com	1969-12-31T23:59:59.000Z	171
p.SegmentationData	portal.office.com	2019-02-23T08:38:13.403Z	121
s.AjaxSessionKey	portal.office.com	1969-12-31T23:59:59.000Z	116
WT_O365_FPC	portal.office.com	2019-03-14T05:28:14.000Z	84
US2-ARRAffinity	.office.com	1969-12-31T23:59:59.000Z	79
NAP	.office.com	1969-12-31T23:59:59.000Z	76
_mkto_trk	.office.com	2020-08-16T08:12:18.000Z	65
AADNonce	.office.com	1969-12-31T23:59:59.000Z	63
MSFPC	.office.com	2019-08-03T07:53:55.000Z	59
p.TenantCulture	portal.office.com	2019-08-14T09:10:55.204Z	58
optimizelyEndUserId	.office.com	2020-09-27T15:05:59.000Z	55
p.FirstLoginDateTimeUtc	portal.office.com	2019-02-23T08:38:13.403Z	55
s.ImpressionId	portal.office.com	1969-12-31T23:59:59.000Z	50

The rest still add up to over 1000 bytes.

Unfortunately, this has definitely not been resolved!