Bug 1280313 - Multiple client command execution through SOAP interface does not authenticate correctly
Multiple client command execution through SOAP interface does not authenticat...
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
urgent Severity urgent
: CR2
: 6.2.0
Assigned To: Shelly McGowan
Ivo Bek
: Regression
Depends On:
  Show dependency treegraph
Reported: 2015-11-11 08:08 EST by Tomas Livora
Modified: 2018-01-30 23:45 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Livora 2015-11-11 08:08:27 EST
Description of problem:
We have a test case which tries to run a process using SOAP with invalid credentials. The test passes (exception is thrown) if it is run alone. However, if other SOAP test is run before, no exception is thrown. I think this means that SOAP is using the user credentials from previous test and so it is not stateless as it should be.

Version-Release number of selected component (if applicable):
6.2.0 ER5

Steps to Reproduce:
1. Run some commands using SOAP interface with valid credentials.
2. Try to run some command using SOAP interface with invalid credentials.

Actual results:
The command is executed and no exception is thrown

Expected results:
Exception should be thrown

Additional info:
See testNotExistingUser() method here:
Comment 2 Tomas Livora 2015-11-11 11:06:42 EST
I have just tried it with BPMS 6.1 and exception is thrown there. However, the different one when the test is executed alone (RemoteCommunicationException) and with other SOAP tests (WebServiceException). In BPMS 6.2 there is the same exception when the test is executed alone (RemoteCommunicationException) and no exception if it is executed together with other SOAP tests.
Comment 3 Marco Rietveld 2015-11-11 21:42:55 EST

Could you provide a test that reproduces this issue? 

I tried to reproduce the issue in several different ways but was unable to do so. 

At the moment, my suspicion is that this is not a bug, but a weird by-product of the QE tests. However, I've also been wrong about my suspicions quite often!
Comment 4 Marco Rietveld 2015-11-12 01:28:19 EST
Apologies Tomas, it took me a while, but all of a sudden I understood where the mistake was and what was happening. 

Please ignore the above comment.
Comment 5 Marco Rietveld 2015-11-12 02:13:23 EST
However, I do not believe this is a blocker. 

What I'm seeing is the following: 

1. In certain situations, it's possible to _create a client_ with incorrect/unauthorized login information. 
2. However, _requests_ with unauthorized login information are not succeeding. 

This means that the problem is only limited to the creation of clients and does not extend to unauthorized requests.

Tomas and/or Lukash, could you confirm this?
Comment 6 Ivo Bek 2015-11-12 04:21:52 EST
Marco, it seems that the SOAP client is working though it uses wrong credentials.

I checked the jenkins jobs and the test passes all the assertions in the code below:

RemoteController rc = new SOAPCommandController(TestConfig.getApplicationUrl(), IntegrationBase.DEPLOYMENT_ID,
                "IDontExist", "MyPassword");
        ProcessInstance pi = rc.startProcess(DEPLOYMENT_ID, SCRIPT_TASK_PROCESS_ID, null);
        Assertions.assertThat((long) pi.getState()).isEqualTo(ProcessInstance.STATE_COMPLETED);

And the test fails with java.lang.AssertionError: Expected exception: org.kie.remote.client.api.exception.RemoteCommunicationException

In the log I can see the process instance too.

ProcessInstance 1133 [processId=org.jboss.qa.bpms.ScriptTask,state=2]
Comment 12 Marco Rietveld 2015-11-22 11:20:19 EST
Created https://issues.apache.org/jira/browse/CXF-6689
Comment 13 Marco Rietveld 2015-11-23 15:20:33 EST
Maciej has found a likely fix: 


I've confirmed that the same class (AuthValueImpl) also exists in the IBM and Open JDK.
Comment 15 Marco Rietveld 2015-11-24 10:21:05 EST
The following code, if executed before the test, provides a workaround: 


QE, would it be possible for you to verify this workaround on the test today? (Nov 24th)
Comment 16 Lukáš Petrovický 2015-11-24 10:24:42 EST
(In reply to Marco Rietveld from comment #15)
> QE, would it be possible for you to verify this workaround on the test
> today? (Nov 24th)

Unfortunately not. :-( Everybody gone already. First thing in the morning, though.
Comment 17 Tomas Livora 2015-11-25 03:05:52 EST
Marco, I have just tested it and our reproducer passes when I execute that method before each test. So it seems the issue is fixed by this workaround.
Comment 19 Ivo Bek 2015-12-01 07:18:27 EST
Verified in BPM Suite 6.2.0.CR2

Note You need to log in before you can comment on or make changes to this bug.