Authentification strategy - Response with access_token

Making Packs
1

Hello,

To practice a little, I am trying to build a pack for the telegra.ph API.

To create an account, we have to pass different parameters, then the response provides an access token we have to pass as query for each request.

I believe there are two options:

  1. In the pack configuration, a form with all the parameters,
  2. A formula to create an account.

According to the different authentication methods, option 1 is impossible.
The second option has some advantages, but is there a way to use QueryParamToken inside a formula to set up the account with a securely method?

Any help could be usefull.

Have a good day

2

Hi @j.b_o - What an interesting challenge! You are correct that option #1 isn’t possible, since the auth system was designed to connect to existing accounts, not create new ones. Option #2 is possible, and you’d want to do something like:

  1. Write a CreateAccount() action formula that takes in the required information and returns the account info (including the access_token). This would be annotated with connectionRequirement: coda.ConnectionRequirement.None to indicate that it doesn’t require any auth.

  2. Use QueryParamToken auth for the rest of the Pack.

Users would first run the CreateAccount() action formula (perhaps as part of a published doc) to generate their account, and then copy the resulting access token. When they later auth with the Pack they would paste in that token.

3

Thank you @Eric_Koleda for your quick answer.

You confirm my deductions.

Capture d’écran du 2023-10-26 23-09-32

I understood that the authentication methods allowed the code to be separated from the credentials and token. To understand clearly, if we execute CreateAccount() in the document, the token is stored in plain text and is accessible. In this case, is it useful to go through an authentication method again? It could be useful to manager different accounts but not for security purpose, couldn’t it?

4

It’s hard to say what the right approach is, but I think it’s safer in the long run to store the access token in Coda’s authentication storage vs the document.

5

Thank you @Eric_Koleda for your confirmation and your help.

Futhermore, I couldn’t find it in the documentation:

  • Is it possible to built a table in a pack which is not a sync data table? Just a pre-config table with column and button.
  • Is it possible to make a self reference schema out of the table context. For exemple :
let NodeSchema = coda.makeObjectSchema({
  properties: {
    tag: { type: coda.ValueType.String },
    attrs: { type: coda.ValueType.Object, items: NodeAttrsSchema }, 
    children: { type: coda.ValueType.Array, items: NodeSchema } // <<<<<< ?
  }
});
6

This can be accomplished using templates. In the Pack listing you can specify a set of featured docs, which show up as templates in the Pack’s side panel. Users can then drag and drop those templates into their docs.

image

Yes, one way to accomplish this is to manually create the reference schema first, as shown in this sample Pack:

In the full version of the Todoist sample I show a slight different approach, that involves using a helper function to generate the reference schema, and then tacking on the new property after:

7

Ok, i will think about it when the pack will be clean enough.

I try the first approach without success.
I will retry about it later :

const NodeReferenceSchema = coda.makeObjectSchema({
  codaType: coda.ValueHintType.Reference,
  properties: {
    tag: { type: coda.ValueType.String, required: true, },
    attrs: {
      type: coda.ValueType.Object,
      properties: {
        src: { type: coda.ValueType.String },
        id: { type: coda.ValueType.String },
        href: { type: coda.ValueType.String, codaType: coda.ValueHintType.Url },
        target: { type: coda.ValueType.String },
      },
    },
  },
  displayProperty: "tag",
  idProperty: "tag",
  identity: {
    name: "Node",
  },
});

let NodeSchema = coda.makeObjectSchema({
  properties: {
    tag: { type: coda.ValueType.String, required: true, }, 
    attrs: {
      type: coda.ValueType.Object,
      properties: {
        src: { type: coda.ValueType.String },
        id: { type: coda.ValueType.String },
        href: { type: coda.ValueType.String, codaType: coda.ValueHintType.Url },
        target: { type: coda.ValueType.String },
      },
    },    
    //children: { type: coda.ValueType.Array, items: NodeSchema }
    displayProperty: "tag",
    parentNode: NodeReferenceSchema,
    idProperty: "tag",
  }
});

One thing make me worry is that there is no “Id” for the node, i guess i have to invent it. For exemple, an excerpt of API answer actually :

            {
                "tag": "figure",
                "children": [
                    {
                        "tag": "img",
                        "attrs": {
                            "src": "/file/f701e9b51469a318f166b.jpg"
                        }
                    },
                    {
                        "tag": "figcaption",
                        "children": [
                            ""
                        ]
                    }
                ]
            },
            {
                "tag": "h3",
                "attrs": {
                    "id": ""
                },
                "children": [
                    {
                        "tag": "br"
                    }
                ]
            },
8

Hello,

Finally i decide to switch from the web editor to CLI to use various javaScript libraries.
As i read in the doc, it should work with window, document, etc…

I try the suggested formula by telegra.ph to transform node into dom :

export function nodeToDom(node) {
  if (typeof node === 'string' || node instanceof String) {
    return document.createTextNode(node);
  }
...

I get a error :
ReferenceError: document is not defined

So i guess i need to find a way to emulate the document?

9

No, window and document are Web-only APIs and not part of the ECMAScript standard that the Packs runtime was built on. There are some libraries that can be used to emulate a DOM on the server, but I don’t know if it’s possible to get them running in a Pack. In general you should stick to libraries that are “Pure JavaScript” and don’t rely on the Web- or Node-specific APIs.

10

Thank you for the answer and for the help.
The pack is on good way… But i face to a big problem that need some help. I will open another post tomorrow… :person_shrugging: