langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-23 13:05:55 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

The API authentication for HTTP requests in the workflow is invalid. #15420

New Issue
Closed
opened 2026-02-21 19:21:38 -05:00 by yindo · 17 comments
yindo commented 2026-02-21 19:21:38 -05:00
Owner
Copy Link
Copy Source

Originally created by @owen-chang001 on GitHub (Jul 16, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.6.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. open a workflow
  2. add a http request tag
  3. use api-key button in the tag to get my authentication(for this http request, i use the Bearer way to set)
  4. request an HTTP data packet

✔️ Expected Behavior

can request success

❌ Actual Behavior

Image can't post success, but if i manully set the api_key into headers , it will success - is the code logic of this api_key button wrong?that took me a lot of time T_T
Originally created by @owen-chang001 on GitHub (Jul 16, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.6.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. open a workflow 2. add a http request tag 3. use api-key button in the tag to get my authentication(for this http request, i use the Bearer way to set) 4. request an HTTP data packet ### ✔️ Expected Behavior can request success ### ❌ Actual Behavior <img width="728" height="259" alt="Image" src="https://github.com/user-attachments/assets/a338fe5d-a995-47ae-bfa0-cabf0fe1ad0f" /> can't post success, but if i manully set the api_key into headers , it will success - is the code logic of this api_key button wrong?that took me a lot of time T_T
yindo closed this issue 2026-02-21 19:21:39 -05:00
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jul 16, 2025):

Your suspicion is correct: there's likely a bug or mismatch in how the api-key button sets up the Authorization header for Bearer authentication. The frontend UI does collect the API key and type, but if manual header entry works and the button does not, it's probable that the backend logic isn't formatting or injecting the header as expected when using the button. This could be due to a missing "Bearer " prefix, incorrect field mapping, or the header not being set at all in the outgoing request when the button is used. The backend code responsible for this logic is in the workflow HTTP request node implementation, specifically in how it processes the authorization config and constructs the request headers (source).

As a workaround, continue manually setting the Authorization header in the headers section for now. If you want to debug further, you could compare the actual outgoing headers (using a proxy or logging) between the two methods to confirm the difference.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jul 16, 2025): <!-- Answer --> Your suspicion is correct: there's likely a bug or mismatch in how the api-key button sets up the Authorization header for Bearer authentication. The frontend UI does collect the API key and type, but if manual header entry works and the button does not, it's probable that the backend logic isn't formatting or injecting the header as expected when using the button. This could be due to a missing "Bearer " prefix, incorrect field mapping, or the header not being set at all in the outgoing request when the button is used. The backend code responsible for this logic is in the workflow HTTP request node implementation, specifically in how it processes the authorization config and constructs the request headers [(source)](https://github.com/langgenius/dify/blob/4a2169bd5f6632a38fa25178d608a6e5cafd0121/api/core/workflow/nodes/http_request/entities.py). As a workaround, continue manually setting the Authorization header in the headers section for now. If you want to debug further, you could compare the actual outgoing headers (using a proxy or logging) between the two methods to confirm the difference. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/e9142b48-c7d4-41bc-b866-5d8bc12fc3c3?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/e9142b48-c7d4-41bc-b866-5d8bc12fc3c3?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/e9142b48-c7d4-41bc-b866-5d8bc12fc3c3?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/e9142b48-c7d4-41bc-b866-5d8bc12fc3c3?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e9142b48-c7d4-41bc-b866-5d8bc12fc3c3?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/e9142b48-c7d4-41bc-b866-5d8bc12fc3c3?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e9142b48-c7d4-41bc-b866-5d8bc12fc3c3?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/22484)
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Jul 16, 2025):

Can you paste the screenshots of the auth button?

@crazywoola commented on GitHub (Jul 16, 2025): Can you paste the screenshots of the auth button?
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

@crazywoola that picture i pasted

Image
@owen-chang001 commented on GitHub (Jul 16, 2025): @crazywoola that picture i pasted <img width="728" height="259" alt="Image" src="https://github.com/user-attachments/assets/acd396b4-5486-4fe1-ad9c-05a5214d3147" />
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

in http request tag in workflow

@owen-chang001 commented on GitHub (Jul 16, 2025): in http request tag in workflow
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Jul 16, 2025):

I want to see the configuration you selected in the image after you clicked on it.

Image
@crazywoola commented on GitHub (Jul 16, 2025): I want to see the configuration you selected in the image after you clicked on it. <img width="2134" height="1444" alt="Image" src="https://github.com/user-attachments/assets/7e776b98-4f10-41db-b2a6-a8a66d271b31" />
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

@crazywoola yeah, same with your picture, API-key and Bearer,after i put my api-key into the textbox, the result is this

Image
@owen-chang001 commented on GitHub (Jul 16, 2025): @crazywoola yeah, same with your picture, API-key and Bearer,after i put my api-key into the textbox, the result is this <img width="749" height="737" alt="Image" src="https://github.com/user-attachments/assets/ef7b8c8f-cb0f-473d-8863-87f2b1caa0f2" />
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

@crazywoola but if i put my same api-key into headers part, request will be success.

@owen-chang001 commented on GitHub (Jul 16, 2025): @crazywoola but if i put my same api-key into headers part, request will be success.
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Jul 16, 2025):

Yes, I want to see the content inside, you can use *** instead. Not sure if you have entered "Bearer ****"

@crazywoola commented on GitHub (Jul 16, 2025): Yes, I want to see the content inside, you can use *** instead. Not sure if you have entered "Bearer ****"
yindo commented 2026-02-21 19:21:39 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

Image i might be understand what you think of, my api-key format should be right, right?
@owen-chang001 commented on GitHub (Jul 16, 2025): <img width="621" height="477" alt="Image" src="https://github.com/user-attachments/assets/9af0399a-9419-42cb-a67e-088f99b3a250" /> i might be understand what you think of, my api-key format should be right, right?
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Jul 16, 2025):

Yes. Can you try Custom with "Bearer sk-xxxxxxxx" to see if it works.

@crazywoola commented on GitHub (Jul 16, 2025): Yes. Can you try Custom with "Bearer sk-xxxxxxxx" to see if it works.
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

nope, that doesn't work

Image Image
@owen-chang001 commented on GitHub (Jul 16, 2025): nope, that doesn't work <img width="578" height="391" alt="Image" src="https://github.com/user-attachments/assets/1c90836c-f01b-44cc-9b13-f81c303c5d26" /> <img width="749" height="745" alt="Image" src="https://github.com/user-attachments/assets/e01cbbef-d0b8-4126-8eea-b7953235afda" />
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@ACAne0320 commented on GitHub (Jul 16, 2025):

I think you only need to try two of the following:

  1. Authorization: Bearer sk-your-api-key
Image
  1. Authorization: sk-your-api-key
Image
@ACAne0320 commented on GitHub (Jul 16, 2025): I think you only need to try two of the following: 1. Authorization: Bearer sk-your-api-key <img width="517" height="462" alt="Image" src="https://github.com/user-attachments/assets/f4c05caa-4be6-421a-adfa-502d70800c69" /> 2. Authorization: sk-your-api-key <img width="537" height="481" alt="Image" src="https://github.com/user-attachments/assets/2d599e5f-a07b-4eea-a95c-8b37c8ed230b" />
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

Image Image same response, have you request successed with these kind of Authorization?
@owen-chang001 commented on GitHub (Jul 16, 2025): <img width="563" height="485" alt="Image" src="https://github.com/user-attachments/assets/dad5dd79-d929-4e1d-b5fd-2ccdcb19dfb5" /> <img width="723" height="704" alt="Image" src="https://github.com/user-attachments/assets/ce6db574-e70a-41bc-9408-832b54986e07" /> same response, have you request successed with these kind of Authorization?
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@ACAne0320 commented on GitHub (Jul 16, 2025):

I think the request header should be Authorization and not api_key

Can you try again?

@ACAne0320 commented on GitHub (Jul 16, 2025): I think the request header should be **Authorization** and not **api_key** Can you try again?
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

@ACAne0320 that's helpful ,i requests successful @crazywoola my mistake, thanks a lot

@owen-chang001 commented on GitHub (Jul 16, 2025): @ACAne0320 that's helpful ,i requests successful @crazywoola my mistake, thanks a lot
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@ACAne0320 commented on GitHub (Jul 16, 2025):

Which way are you using to make the request successful?

  1. Authorization: Bearer sk-your-api-key
  2. Authorization: sk-your-api-key

If it's the second way, I don't think it's necessary to specify the Bearer header in that request, which is why when you initially use API-Key -> Bearer -> sk-your-api-key, the request fails.

When you choose API-Key -> Bearer -> sk-your-api-key you are actually sending the following request header (the first way), which splices Bearer before your API-Key, like this:
Authorization: Bearer sk-your-api-key

Related: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization

@ACAne0320 commented on GitHub (Jul 16, 2025): Which way are you using to make the request successful? 1. Authorization: Bearer sk-your-api-key 2. Authorization: sk-your-api-key If it's the second way, I don't think it's necessary to specify the Bearer header in that request, which is why when you initially use `API-Key -> Bearer -> sk-your-api-key`, the request fails. When you choose `API-Key -> Bearer -> sk-your-api-key` you are actually sending the following request header (the first way), which splices Bearer before your API-Key, like this: `Authorization: Bearer sk-your-api-key` Related: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization
yindo commented 2026-02-21 19:21:40 -05:00
Author
Owner
Copy Link
Copy Source

@owen-chang001 commented on GitHub (Jul 16, 2025):

Image @ACAne0320 i learned what you said just now, thanks and what i used is the third way, user-defined, so i add Bearer
@owen-chang001 commented on GitHub (Jul 16, 2025): <img width="560" height="458" alt="Image" src="https://github.com/user-attachments/assets/f9a559d0-f642-4329-9c9a-bc56ff9f61e1" /> @ACAne0320 i learned what you said just now, thanks and what i used is the third way, user-defined, so i add Bearer
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15420
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?