![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Nov. 1st, 2022 02:29 pmMicrosoft is the haunted house of technical solutions. Trying to convert apps that were using IMAP to Azure Graph, for one particular user (who happens to be the user account that runs an important app), I started getting an "ErrorInvalidIdMalformed : Id is malformed" error on a request to move a message. The same code works fine in other cases. I double and triple checked I'm giving them back exactly the same ID they gave me as the ID for the message.
Googling this, I found something awful:
https://social.msdn.microsoft.com/Forums/office/en-US/d44c595b-2895-4491-9074-afe82cd5da79/office365-calendar-api-create-fails-returning-quoterrorinvalididmalformed-id-is?forum=Office365forDevelopers
This person is working around the error by base64 decoding the ID (and the IDs do look like base64 encoded data), changing characters around to replace "naughty" characters like dashes, base64 encoding it again, and then using that. So, basically, when Microsoft gives you an ID, you have to process it in specific ways and then give them back a different ID. Microsoft cannot process their own IDs. And since the base64 data encoded inside of these IDs includes a GUID, there will always be dashes.
The whole point of an ID is an unambiguous reference to data. It isn't supposed to contain data. It's a stand-in for data. It isn't supposed to be parsed or processed or verified in any way except that it is a valid reference to data that the user has access to view. They are failing to meet the criteria for an ID is in every possible way simultaneously.
Filing a bug report earlier with Microsoft, which Microsoft insisted as treating as a support request for something completely different than what the problem was reported on, the report from requested the entire, exact error message, then refused the data because the error message contained <> characters. Microsoft collectively doesn't seem to understand the basic concepts of handling data as binary, escaping output to include in HTML, or IDs, so really, this company has not changed in the last two decades.
Googling this, I found something awful:
https://social.msdn.microsoft.com/Forums/office/en-US/d44c595b-2895-4491-9074-afe82cd5da79/office365-calendar-api-create-fails-returning-quoterrorinvalididmalformed-id-is?forum=Office365forDevelopers
This person is working around the error by base64 decoding the ID (and the IDs do look like base64 encoded data), changing characters around to replace "naughty" characters like dashes, base64 encoding it again, and then using that. So, basically, when Microsoft gives you an ID, you have to process it in specific ways and then give them back a different ID. Microsoft cannot process their own IDs. And since the base64 data encoded inside of these IDs includes a GUID, there will always be dashes.
The whole point of an ID is an unambiguous reference to data. It isn't supposed to contain data. It's a stand-in for data. It isn't supposed to be parsed or processed or verified in any way except that it is a valid reference to data that the user has access to view. They are failing to meet the criteria for an ID is in every possible way simultaneously.
Filing a bug report earlier with Microsoft, which Microsoft insisted as treating as a support request for something completely different than what the problem was reported on, the report from requested the entire, exact error message, then refused the data because the error message contained <> characters. Microsoft collectively doesn't seem to understand the basic concepts of handling data as binary, escaping output to include in HTML, or IDs, so really, this company has not changed in the last two decades.
