SOLVED

Portal giving Bad Request error again

MVP

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.

 

requesttoobig.png

 

 

 

 

 

 

 

 

 

 

 

 

 

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

18 Replies

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

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

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.

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.

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.

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!

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 :)

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

Good news. Thanks for the update.

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...

best response confirmed by VI_Migration (Silver Contributor)
Solution

Hi Vasil,

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

thanks,

Anne

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.

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

Thanks,

Anne

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.

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

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?

+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..

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!

 

1 best response

Accepted Solutions
best response confirmed by VI_Migration (Silver Contributor)
Solution

Hi Vasil,

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

thanks,

Anne

View solution in original post