1

Summary - Currently the Directory API User Photo's photo data (encoded as web-safe Base64) handles padding in a way that contradicts the documentation; padding should be converted from = to . but instead requires =. Looking for clarification of if this is intended or not.

Details - I have been using the Google API to interface with the User Photos - being able to retrieve and update. The documentation is clear as to how the Web-Safe Base64 format for the photo data needs to be presented:

For padding, the period (.) character is used instead of the RFC-4648 baseURL definition which uses the equals sign (=) for padding. This is done to simplify URL-parsing.

However, recently this has stopped working. I'm unsure of exactly when this happened. (Edit: Based on similar comments from years ago that I'm finding, this may have never worked and I just never happened to test a photo that encoded into something with padding.)

To test this I downloaded an existing image and re-uploaded it, and got the error Invalid value for ByteString. If I intercept the Base64 being returned and pass that same data back directly, I get no error.

The issue turned out to be the padding - in the documentation it states the = equals padding needs to be replaced with a . period. My example Base64 ended with two padding characters, which were turned into two periods as expected (and this gives the error). If I instead leave the padding as the = equals, it works no problem.

Turns out the Base64 being returned from Google when you retrieve a user photo also has the padding with = equals characters, which seems to clearly contradict the documentation. I have also confirmed this through the Try It Now methods via the web, so it's not language or API Client-specific.

So, did the process change and the documentation (last updated Feb 26th, 2015) isn't updated? Is this a permanent change or a bug?

Edit - According to some other posts it looks like this has been a longstanding issue, I may have never run in to an image before that ended up with padding. Point stands - is the documentation accurate, or do I need to adjust for this?

Edit 2 - All signs point to this being either a bug or bad documentation. Either way, I was unable to find any issues in their tracking for this, so I have opened an issue for it. If I get official word in any case I will [try to remember to] come back and provide it as an answer.

Community
  • 1
  • 1
squid808
  • 1,430
  • 2
  • 14
  • 31
  • @PeterHerrmann I personally didn't think it was, that question and others were asking *how* to get it working. Here I explained that I had figured out how, but that wasn't the question. Knowing that StackOverflow is [supposedly monitored by folks at Google](https://developers.google.com/admin-sdk/directory/support) for these questions, I was looking for clarification if this was intended behavior or not. I'll bold the question at the bottom of the post for clarity. – squid808 Apr 12 '17 at 13:49
  • 1
    Hey OP, I have removed my dupe flag but the bottom line is that in my experience, replacing = with . has _never_ worked and _always_ caused some photos to break. I've done this for thousands of photos in a job that's been running and maintained since the apis (profile now admin sdk) have been available. I agree the doc could be wrong and thanks for logging an issue. – Peter Apr 13 '17 at 00:23
  • @PeterHerrmann Thanks for the insight - this part of the API isn't something I use often. Based on this and the fact that I'm seeing folks reporting this for years, I'll work under the assumption that this isn't changing any time soon and move forward until I officially hear otherwise from the powers that be. – squid808 Apr 16 '17 at 03:49

0 Answers0