Custom Authentication in Packs Now Requires Approval?

Do you know how pissed off I was to see this message when I needed to patch my pack with a troublesome issue. Oh great, I need to request approval, probably be denied and told to rebuild it another way after 3 business days! Great!

I’m just here to vent. Why can’t existing packs be grandfathered?

Cleaning up...
Intermediate files are moved to /var/folders/hg/jcl3c8j135n22hy_c619jzdm0000gn/T/coda-packs-31995faa-6529-4e80-bf10-94c1b23340e4ACZWnk
Error while finalizing pack version: {
  statusCode: 400,
  statusMessage: 'Bad Request',
  message: 'Pack metadata failed validation.',
  codaType: 'PackInvalid',
  codaDetail: {
    validationErrors: [
        path: 'metadata.defaultAuthentication.type',
        message: 'Packs must be explicitly approved to use Custom authentication. To request approval contact Coda support at'

Also why does this matter if my Pack is never going to be released to the public and is for internal use? Can’t I just use what I have built?



I wasn’t aware of this. Sounds ominous.

1 Like

Hi @orth - Ya, it sucks to hit a wall like that, and I apologize for the experience. A few months back we introduced an approval process for Custom auth to address a security issue, although I don’t think we announced it widely beyond updating the documentation. We did add exceptions for some legacy published Packs, but we may not have included internal Packs.

I oversee the approval process, and in general it should be quick and painless. There are cases where we push back on the use Custom auth in favor of another option, but this tends to be a small code change.

As for why internal Packs are not exempted, it’s a complex issue we’ve thought a lot about. In general all of our approval processes exist to protect users from malicious Packs, and in general we believe that internal users within a company should likely be protected all the same. While the chance of a bad actor popping up within a company is likely lower, it is a risk that does exist.

I think there is more we could do to target these protections or balance them against developer productivity, but I hope this gives some context on the current state.


I appreciate the thoughtful response, Eric. Obviously, at the time my emotions were elevated. I’ve had to to resort instead to pushing data to Coda through the API instead of pulling it using my Pack.

This issue is exacerbated as I’m no longer the Admin of my pack I develop as I handed it over (the one that’s live). The reason for this is its in the hands of my company’s SecOPS team so in case something happens to me they can easily manage things and additionally I can’t arbitrarily add functionality that they have not vetted.

So now I have to request SecOPS to perform the request for Approval of Custom Authentication and their time is very limited and I don’t really wish to be a go-between either.

My Custom Authentication is for HelpScout using Client Credentials Authentication | Help Scout Developers - we used this instead of OAuth2 because employees can move on and be removed from Coda thus breaking our functionality.

Anyway, I think I may just resort to no longer maintaining this pack and instead just using the Coda API instead.

Take care,

Thank you for the additional details, and for your candor. I completely understand the hesitancy to bother your colleagues with this busy work, but if you do ever want to move it back to a Pack it should be approved without any hassle.

We have had a lot of request to support a client_credentials OAuth flow, and the team plans to tackle it in the coming months. In the mean time we have been approving Custom auth as a workaround.

1 Like

Blame me for this :slight_smile: I found the security issue with Custom and even got paid for it. Can’t disclose much more other than there was an attack vector and the only solution was to introduce manual checks.

Fun fact, I then fell victim to this scrutiny myself. Wanted to use custom multiple times, sometimes got denied :slight_smile:

1 Like