Project

General

Profile

bug #8848

Search fails with low data rate network (64kbit/s) network connection due to lost authentication

Added by Andreas Kohlbecker 5 months ago. Updated 5 months ago.

Status:
Feedback
Priority:
Highest
Category:
taxeditor
Target version:
Start date:
02/14/2020
Due date:
% Done:

50%

Severity:
normal
Found in Version:

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 issues

Related to Edit - bug #8812: Connection losses in taxeditor HTTP invoker (RemoteAccessException: Could not access HTTP invoker remote service at ...) Resolved 01/16/2020
Related to Edit - task #8841: clean up application context configuration In Progress 02/04/2020

Associated revisions

Revision 5a87d221 (diff)
Added by Andreas Kohlbecker 5 months ago

ref #8848 switching from thread local to global secutity context holder strategy

History

#1 Updated by Andreas Kohlbecker 5 months ago

  • Related to bug #8812: Connection losses in taxeditor HTTP invoker (RemoteAccessException: Could not access HTTP invoker remote service at ...) added

#2 Updated by Andreas Kohlbecker 5 months ago

  • Related to task #8841: clean up application context configuration added

#3 Updated by Andreas Kohlbecker 5 months ago

  • 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.

#4 Updated by Katja Luther 5 months ago

  • 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.

#5 Updated by Andreas Müller 5 months ago

  • 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.

#6 Updated by Andreas Kohlbecker 5 months ago

  • 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

Add picture from clipboard (Maximum size: 40 MB)