starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-25 22:05:59 +03:00

[GH-ISSUE #2001] Embed Authoring Failing with 401 Due to Embed Component Not Sending Auth Token #571

New issue

Open

opened 2026-02-26 18:47:38 +03:00 by kerem · 2 comments

kerem commented

2026-02-26 18:47:38 +03:00

Owner

Originally created by @JarodTAerts on GitHub (Aug 27, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/2001

I am trying to get Embed Authoring with a self-hosted documenso server working with the Documenso embed package (@documenso/embed-react). The normal self-hosted documenso web app deployed on the server works fine, but the embeds are failing due to auth issues. The embed overall works fine, but then when calling the embeddingPresign.createEmbeddingDocument endpoint to create a new document it fails with a 401. This would denote something is going wrong with the Documenso API key we are using or the presign Token. First I checked the API key which was not expired and working fine. Then through extensive logging I verified that the presign token was being generated correctly and looked correct.

Then I noticed that the request that was being made from the embed looked a little off. I would have expected the presign token JWT to be sent via the authorization header.... but in the network tab of the browser I see it is not being sent and the Auth header is just "Bearer ". I did see the referer header was set and included the token as I expected it. I thought for a minute maybe the Documenso server was expecting the referer header and handled that in this case, but I found that the server code is in fact expecting the Auth header to be set: github.com/documenso/documenso@184ebdedf1/packages/trpc/server/embedding-router/create-embedding-document.ts (L18) Further, I added some extra logging to our Documenso deployment to verify that the token we were trying to decrypt was not set as expected.

Request: POST https://sign.dropback.app/api/trpc/embeddingPresign.createEmbeddingDocument?batch=1
Important Headers
authorization: Bearer
referer: https://sign.dropback.app/embed/v1/authoring/document/create?token=eyJhbGciOiJI*********

This points to possibly some incompatibility with how the documenso embed is formatting the auth headers for the request to create the document from the embed. I am wondering if this might be some known issue or if there is something that we might be doing wrong that could be causing this behavior. I don't seem to be able to peak too much into the documenso embed code to investigate much further which is why I am making this issue.

Since this could also be caused by a misconfigured embed object, I will provide our intialize of the object for reference. I did print out the presignToken right before the initalization of this to verify it was as expected and even decoded it to ensure it contained the fields that I expected.

<EmbedCreateDocument
            host={process.env.NEXT_PUBLIC_DOCUMENSO_URL}
            className={styles.frame}
            presignToken={presignToken}
            externalId={props.contract.raw.id}
            darkModeDisabled
            onDocumentCreated={(data) => {
              handleDocumentCreation(data);
            }}
            features={{
              allowConfigureSignatureTypes: false,
              allowConfigureLanguage: false,
              allowConfigureDateFormat: false,
              allowConfigureTimezone: false,
              allowConfigureRedirectUrl: false,
              allowConfigureCommunication: false,
            }}
            css={embeddedCss}
          />

Overall, want to understand if there might be something I am doing wrong here? Or if its possible that there is some issue with the way the embed is constructing the Auth header which is not working in this case? In the very worst case, I think I could modify the server code for our deployment to use the referer header instead of the Auth header for this case..... but would really like to avoid that since it would be a major deviation from the main upstream codebase.

Originally created by @JarodTAerts on GitHub (Aug 27, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/2001 I am trying to get Embed Authoring with a self-hosted documenso server working with the Documenso embed package (@documenso/embed-react). The normal self-hosted documenso web app deployed on the server works fine, but the embeds are failing due to auth issues. The embed overall works fine, but then when calling the embeddingPresign.createEmbeddingDocument endpoint to create a new document it fails with a 401. This would denote something is going wrong with the Documenso API key we are using or the presign Token. First I checked the API key which was not expired and working fine. Then through extensive logging I verified that the presign token was being generated correctly and looked correct. Then I noticed that the request that was being made from the embed looked a little off. I would have expected the presign token JWT to be sent via the authorization header.... but in the network tab of the browser I see it is not being sent and the Auth header is just "Bearer ". I did see the referer header was set and included the token as I expected it. I thought for a minute maybe the Documenso server was expecting the referer header and handled that in this case, but I found that the server code is in fact expecting the Auth header to be set: https://github.com/documenso/documenso/blob/184ebdedf1051b99ab9da83d57faf541c81dad77/packages/trpc/server/embedding-router/create-embedding-document.ts#L18 Further, I added some extra logging to our Documenso deployment to verify that the token we were trying to decrypt was not set as expected. __Request:__ POST https://sign.dropback.app/api/trpc/embeddingPresign.createEmbeddingDocument?batch=1 __Important Headers__ _authorization: Bearer referer: https://sign.dropback.app/embed/v1/authoring/document/create?token=eyJhbGciOiJI*********_ This points to possibly some incompatibility with how the documenso embed is formatting the auth headers for the request to create the document from the embed. I am wondering if this might be some known issue or if there is something that we might be doing wrong that could be causing this behavior. I don't seem to be able to peak too much into the documenso embed code to investigate much further which is why I am making this issue. Since this could also be caused by a misconfigured embed object, I will provide our intialize of the object for reference. I did print out the `presignToken` right before the initalization of this to verify it was as expected and even decoded it to ensure it contained the fields that I expected. ```typescript <EmbedCreateDocument host={process.env.NEXT_PUBLIC_DOCUMENSO_URL} className={styles.frame} presignToken={presignToken} externalId={props.contract.raw.id} darkModeDisabled onDocumentCreated={(data) => { handleDocumentCreation(data); }} features={{ allowConfigureSignatureTypes: false, allowConfigureLanguage: false, allowConfigureDateFormat: false, allowConfigureTimezone: false, allowConfigureRedirectUrl: false, allowConfigureCommunication: false, }} css={embeddedCss} /> ``` Overall, want to understand if there might be something I am doing wrong here? Or if its possible that there is some issue with the way the embed is constructing the Auth header which is not working in this case? In the very worst case, I think I could modify the server code for our deployment to use the referer header instead of the Auth header for this case..... but would really like to avoid that since it would be a major deviation from the main upstream codebase.

kerem added the

Stale

status: triage

labels

2026-02-26 18:47:38 +03:00

kerem commented

2026-02-26 18:47:38 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Aug 27, 2025):

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

@github-actions[bot] commented on GitHub (Aug 27, 2025): Thank you for opening your first issue and for being a part of the open signing revolution! <br /> One of our team members will review it and get back to you as soon as it possible 💚 <br /> Meanwhile, please feel free to hop into our community in [Discord](https://documen.so/discord)

kerem commented

2026-02-26 18:47:38 +03:00

Author

Owner

@hammadyounas commented on GitHub (Oct 27, 2025):

Same issue, needs an update. Embedding is also not working for me when passing the document token while sign embed

@hammadyounas commented on GitHub (Oct 27, 2025): Same issue, needs an update. Embedding is also not working for me when passing the document token while sign embed

kerem referenced this issue

2026-02-26 19:31:38 +03:00

[PR #571] [MERGED] fix: support mailto link fix #1054

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#571

No description provided.

Rows
Columns