EDIT

Do you know about any reason why the thread local strategy has been used? If not we can close this ticket.

Andreas Kohlbecker wrote:

Do you know about any reason why the thread local strategy has been used? If not we can close this ticket.

No, I don't know why this strategy was used.

I do not fully understand this discussion. How can the thread strategy influence if authenticaion fails with a low data rate. To me this is completely unconnected and therefore I do not understand why this ticket can be closed by changing the strategy.

Also I am not familiar with the client security at all. How far do we need something like SecurityContextHolder on client side. There are a couple of questions I have. Maybe we can discuss them in the team on Monday and then decide if the ticket can be closed or not.

It is a question of which context holder strategy is being used in the application. By default ThreadLocalSecurityContextHolderStrategy is being used. This causes each thread to have a separate SecurityContextHolder instance. After successful authentication the LoginDialog puts the users authentication into the SecurityContext which stored in the SecurityContextHolder`

The credentials which are stored in the SecurityContext are required for the HTTP Basic authentication in order to access the HttpInvoker service. The search is running in a separate thread. From within this thread it is impossible to access the SecurityContext since is is hold in a thread local.

From this perspective it is obvious that ThreadLocalSecurityContextHolderStrategy can't be right. The global strategy is much more appropriate for a desktop application, since you want to have the same authetication available in all parts and threads of the application. The thread local strategy is right for server application where it is required to separate the authentications per worker thread. Otherwise all request handling would be share the same authentication, which would be a big security problem.

If you don't know any reason why the ThreadLocalSecurityContextHolderStrategy has been used, only that it is the default, I suggest closing this issue. The fact that the symptoms of this bug only occur with low data rate + high latency connections can be irritating but are explainable. Once authenticated the authentication at the web service persists for some time, it is not need to send the HTTP Authorization Header with each request, but sometimes is is necessary and then it is crucial that you can access the security context.