Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SEC-2703: ChannelSecurityInterceptor should use ThreadLocal for InterceptorStatusToken #2928

Closed
spring-issuemaster opened this issue Aug 18, 2014 · 1 comment
Assignees
Labels
Milestone

Comments

@spring-issuemaster
Copy link

@spring-issuemaster spring-issuemaster commented Aug 18, 2014

Rob Winch (Migrated from SEC-2703) said:

I am running into a problem on how best to support around advice with ChannelInterceptor. Right now I have something like:

public Message<?> preSend(Message<?> message, MessageChannel channel) {
    InterceptorStatusToken token = beforeInvocation(message);
    return token == null ? message : new TokenMessage(message,token);
}

public void postSend(Message<?> message, MessageChannel channel, boolean sent) {
    if(!(message instanceof TokenMessage)) {
        // TODO What if other classes return another instance too?
        return;
    }
    InterceptorStatusToken token = ((TokenMessage)message).getToken();
    afterInvocation(token, null);
}

The problem is that the postSend needs to perform some cleanup based upon actions taken in the preSend. Right now I am returning a custom Message implementation that can be used to perform the cleanup. As I see it this may have a few problems.

  1. The first is that if there is another ChannelInterceptor, it may also wrap the Message object. In that instance, there would be no way to recover the TokenMessage.

  2. The second issue is that users may rely on a specific Message implementation

  3. The final issue is that I'm not sure if changing the type could have other unintentional consequences

One alternative would be to place the token in the header. However, it has some of the same problems since I would have to create a new Message instance (headers is immutable). More importantly, I worry about doing that since headers can be written to by the client which may expose some exploits.

@spring-issuemaster

This comment has been minimized.

Copy link
Author

@spring-issuemaster spring-issuemaster commented Sep 16, 2014

Rob Winch said:

After reviewing this with [~rstoya05-aop] it was determined we should be using a ThreadLocal to store the InterceptorStatusToken and clearing it out in "postSend" and "afterSendCompletion".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.