Better support for coda.ValueHintType.Embed

Developers Central
1

Hello!
I’m looking into building a Lucidchart and Lucidspark pack that allows users to visualize their documents in Coda. Because of the nature of Lucid’s embedded document viewer I need to use the coda.ValueHintType.Embed type. There are a couple of tweaks that would help me build a better experience for Coda and Lucid users.

  1. Be able to identify a formula and where it is being executed.
  • Giving the users the assurance that their documents won’t be displayed in a page they didn’t intend to embed the document is important for Lucid.
  • We can accomplish this by keeping track of the formula and formula location loading a document.

Suggested solution
Make the ExecutionContext.invocationLocation reliable. Add a formulaId field that allows to identify the formula between executions.

  1. Offer display configuration for coda.ValueHintType.Embed types.
  • Lucid documents are visualized better with more space, however, the initial size of an embed is too small. This forces the users to resize the frame every time they insert a document.

Suggested solution
Enable coda.ValueHintType.Embed to configure a bigger size or use the max available width.

I want to recognize how easy and simple the process to create a Pack was. Hopefully both issues/use cases exposed here are generic and would benefit other integrators, not just Lucid. I will be looking out for responses or other ideas.

Regards

2

Hi @Carlos_Amador - Welcome to the Coda community! Those are some great suggestions, thanks for laying out the use cases with such detail. For suggestion #1, " Be able to identify a formula and where it is being executed.", is the idea that you would want to show this information somewhere in the LucidChart app? If so, would an ID alone be enough information? I assume you’d also need the ability to reliable link to that formula ID?

3

Regarding setting the embed size, that is a reasonable request. The only workaround at the moment, which is a bit involved, is to have your content support the oEmbed spec, as mentioned here:

This spec allows an embedded piece of content to specify it’s width and height, which Coda will honor (in non-forced mode).

1 Like
4

Hello @Eric_Koleda!

is the idea that you would want to show this information somewhere in the LucidChart app

It could be used for that, but in our case is to be able to associate a Lucid document embed to an specific formula/location. We have cookie-free Lucid document viewer experience, but to be able to provide that experience in a secure way, we require that association.

I think an id and maybe the Coda document id would be sufficient to make the association.

is to have your content support the oEmbed spec

I will look into the oEmbed spec.

Thanks for answering my message!

5

Can you expand more on how this would help with security? I’d love to have more context to provide to the team here, to make sure we build the right thing.

6

Yes.

We offer two different document viewer experiences:

  1. Cookie auth-based experience: the access to a document relies on the permissions the logged in user has on the embedded document document. For this one, we don’t need anything, we trust only users with access will be able to view the document.

  2. JWT auth-based experience: this one does not rely on cookies, if the embedding application has a valid access token of the user who embedded the document, it can generate a 15 min JWT that grants view access to the document.
    This flow allows documents to be viewed by people that may not even have a Lucid account, anyone with access to the resource where the document is embedded e.g. a Coda document, can see the embedded Lucid document.
    Now in this flow the location of where the user meant to embed a Lucid document is more relevant. We don’t want the document to be displayed in a different Coda document as people who have access to it may be different.
    In the end, we want to able to say Lucid document A was embedded in Coda document X in the formula Y. So that, if for example, someone copies formula Y from Coda document X to Coda document Y, we can tell that the location of the embed is not correct and we can deny loading that document.

7

Thanks for the detailed explanation @Carlos_Amador. For scenario #2, it would seem that you would need that formula ID available in the Pack when the JWT was created, but also somehow transmitted securely at embed time so that you can verify they match. Does that sound right?

8

Yes, that is correct.

9

Thanks for clarifying. Certainly sounds like a bit of a bigger project then, since it would also require changes to how we do embeds more generally. If you are interested in exploring it further, perhaps we should take some time to chat in more detail during one of my office hours slots. You can book time here:

1 Like
10

Alright. I scheduled something.

Thanks for your time!