OpenFeign / OpenFeign/feign

How to handle context of a processing.

Open
#1,600 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feedback provided question
Dominant language
Java
Stars
9.8k
Forks
1.9k
Avg merge
1d 2h
Merged PRs (30d)
41

Description

I need to sign the content of body, then add to head.
The signKey is different for each different user.
So i need to pass signKey to SignRequestInterceptor, the signKey is context.
there is context concept in WebClient, can be retrive in any part of the procedue.

q1:
In feign, is there any official way to save the context?

q2:
We could use header as the context, but the defaultRequestHeaders is added as interceptor after the requestInterceptors.
so we can't get the head in requestInterceptors.

Can feign fix it, change the order?

        defaultRequestHeaders:
          APP_ID: 123
          APP_KEY: abc
        requestInterceptors:
          - club.AuthRequestInterceptor

FeignClientFactoryBean.configureUsingProperties:

		if (config.getRequestInterceptors() != null && !config.getRequestInterceptors().isEmpty()) {
			// this will add request interceptor to builder, not replace existing
			for (Class<RequestInterceptor> bean : config.getRequestInterceptors()) {
				RequestInterceptor interceptor = getOrInstantiate(bean);
				builder.requestInterceptor(interceptor);
			}
		}
                ....
               /
		addDefaultRequestHeaders(config, builder);

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with FeignClientFactoryBean.configureUsingProperties and the RequestInterceptor configuration shown in the issue. Trace how defaultRequestHeaders and requestInterceptors are applied, then determine the supported way to propagate per-user signing context and whether their ordering can be changed. Done means the behavior or official guidance answers both questions and is validated against the relevant configuration flow.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, backend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.