Solved: Encoding issues with base64 fields

omelhus · ‎13-06-2024

Hey,

After the change where the fields marked with [B] in GraphQL automatically converts the value to base64 on the backend instead of accepting base64 the encoding fails. ÆØÅ etc just becomes useless.

This kind of ruins the point of base64, and you need to either roll back the automatic conversion to base64, or check if the value that's being sent is valid base64 and NOT re-encode it.

Cheers

Marius Bancila · ‎20-06-2024

We released a fix for this problem today (https://docs.business.visma.net/docs/releasenotes).

We will be correcting the data that was stored base64 encoded instead of binary.

omelhus · ‎20-06-2024

Thanks! My workaround broke this morning, so I figured you had fixed it 🙂

Marius Bancila · ‎13-06-2024

We are working on fixing the base64 encoding problem.

Marius Bancila · ‎13-06-2024

I suppose the problem you are reporting is that you get back base64-encoded-base64-encoded content.

For instance, an example binary field is htmlFile in emailTemplate table. So I took this HTML text:

<html>
<body>
<h1>Base64-encoding</h1>
</body>
</html>

and encoded it to base-64, which is:

PGh0bWw+Cjxib2R5Pgo8aDE+QmFzZTY0LWVuY29kaW5nPC9oMT4KPC9ib2R5Pgo8L2h0bWw+

And I run the following mutation:

mutation upload_invoice_attachment_directly(
        $cid: Int!,
        $description: String!,
        $data: String!)
{
  useCompany(no :$cid)
  {
    emailTemplate_create(values : [
      {
        description : $description
        htmlFile : $data
      }
    ])
    {
      affectedRows
      items
      {
        emailTemplateNo
        htmlFile
      }
    }
  }
}

with vars:

{
  "cid" : ...,
  "description": "testing base64-encoding",
  "data": "PGh0bWw+Cjxib2R5Pgo8aDE+QmFzZTY0LWVuY29kaW5nPC9oMT4KPC9ib2R5Pgo8L2h0bWw+"
}

What I get back is:

{
  "data": {
    "useCompany": {
      "emailTemplate_create": {
        "affectedRows": 1,
        "items": [
          {
            "emailTemplateNo": 1,
            "htmlFile": "UEdoMGJXdytDanhpYjJSNVBnbzhhREUrUW1GelpUWTBMV1Z1WTI5a2FXNW5QQzlvTVQ0S1BDOWliMlI1UGdvOEwyaDBiV3cr"
          }
        ]
      }
    }
  }
}

At this point, the htmlFile contains base64 in the database and that's what we get back, and then we get back a base64-encoded of a base-64 encoded text.

omelhus · ‎13-06-2024

Well, this was the issue until I figured that out and just started sending a non-base64-encoded string instead.

The issue with sending the non-base64-encoded string is that base64 preserves the windows-1252 or iso-8859-1 encoding that bnxt uses for its labels, but when I send it through the API they get mangled with the utf-8 encoding.

I've managed to partially work around this by latin1 encoding the data first, but this does not totally solve the issue.

Please fix so that I can send base64 in again.

Marius Bancila · ‎13-06-2024

I'm investigating the issue.

Generally speaking, it's always helpful to post the query that has error or works unexpectedly. It's much easier to repro the exact problem.

Encoding issues with base64 fields

Useful pages

About Visma

Contact us

Follow us