bug #8848
open
Search fails with low data rate network (64kbit/s) network connection due to lost authentication
Added by Andreas Kohlbecker about 4 years ago.
Updated about 4 years ago.
Description
During testing the taxeditor with low data rate network conditions 64kbit/s, the search fails, since the authentication is missing. The server responds with HTTP status 401.
Debugging revealed that the search is running in a separate thread but the SecurityContextHolderStrategy being used is set to MODE_THREADLOCAL (default). The login dialog is operating in a different thread (main thread?) so that the authentication is not accessible in the search thread.
Interestingly there is no problem with networks connections having a higher data rate.
As solution I suggest to switch to SecurityContextHolder.MODE_GLOBAL, this anyway is the correct strategy for an desktop client application.
- Related to bug #8812: Connection losses in taxeditor HTTP invoker (RemoteAccessException: Could not access HTTP invoker remote service at ...) added
- Related to task #8841: clean up application context configuration added
- Status changed from New to Resolved
- Assignee changed from Andreas Kohlbecker to Katja Luther
- Priority changed from New to Highest
- % Done changed from 0 to 50
Do you know about any reason why the thread local strategy has been used? If not we can close this ticket.
- Status changed from Resolved to Closed
- Assignee changed from Katja Luther to Andreas Kohlbecker
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.
- Status changed from Closed to Feedback
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.
- Assignee changed from Andreas Kohlbecker to Andreas Müller
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.
Also available in: Atom
PDF