Bug 1012882

Summary: Deploy of springapp war causes continuous auth problems (error 401 - validation fails) in business central
Product: [Retired] JBoss BPMS Platform 6 Reporter: Ivo Bek <ibek>
Component: Business CentralAssignee: Maciej Swiderski <mswiders>
Status: CLOSED CURRENTRELEASE QA Contact: Ivo Bek <ibek>
Severity: high Docs Contact:
Priority: medium    
Version: 6.0.0CC: kverlaen
Target Milestone: ER5   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-06 20:09:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
reproducer, the springapp web archive (part1)
none
reproducer, the springapp web archive (part2)
none
reproducer, the springapp web archive (part3) none

Description Ivo Bek 2013-09-27 10:17:40 UTC
Description of problem:

After I deploy my spring app and then I undeploy it, it's not possible to do any REST operation because every request validation fails on wrong or missing credentials though they are valid. To be more precise, the returned error is 401 - Validation fails.
I don't think it's necessary to have spring app but I reproduced the issue with it. Actually it's another small, and simple business central which probably influence the real business central.

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


How reproducible:


Steps to Reproduce:

First download the reproducer parts and connect them into springapp.war with following command "cat xa* > springapp.war"

1. install bpms 6.0.0.ER3 on EAP 6.1.0 and add some user to check the validations
2. start bpms
3. deploy springapp.war
4. undeploy springapp.war
5. do a REST op. (e.g. GET http://localhost:8080/business-central/rest/repositories with valid credentials in Authorization header)
6. see that you receive 401 though you set the right credentials

Actual results:


Expected results:


Additional info:

Comment 2 Ivo Bek 2013-09-27 10:22:40 UTC
Created attachment 803871 [details]
reproducer, the springapp web archive (part1)

Comment 3 Ivo Bek 2013-09-27 10:24:09 UTC
Created attachment 803873 [details]
reproducer, the springapp web archive (part2)

Comment 4 Ivo Bek 2013-09-27 10:25:13 UTC
Created attachment 803874 [details]
reproducer, the springapp web archive (part3)

MD5 sums

8889d9014f6d31ca76b35481e446248e  xaa
985a0c301bad4558b3496f9eb11845e0  xab
80eeb0f14006e6a9e68acbec5935d181  xac

Comment 5 Maciej Swiderski 2013-09-30 14:42:35 UTC
Ivo, how do you specify authentication header for basic logon? I could not reproduce that exactly as you described. The issue I believe you can experience is that since there are two authentication methods involved (FORM for UI and BASIC for rest) is that the challenge will not be issued so you need to specify the header directly when sending the GET request.
For me it does the same way regardless if the spring app is deployed or not. I tried with different browsers (chrome, firefox, safari) and all behaves the same way.

When using FireFox REST plugin where you can define the authentication header all works as expected.

Comment 6 Ivo Bek 2013-09-30 15:38:01 UTC
Hi Maciej,

 I set the authentication header in the request this way getClientRequestFactory().createRequest(address.toExternalForm()).header("Authorization", AUTH_HEADER) where AUTH_HEADER = "Basic " + Base64.encodeBase64String(String.format("%s:%s", userId, password).getBytes()).trim();
 but it doesn't matter because the REST plugin in firefox with authentication header causes the issue too. It's not important which client I use, the result is always same, the ERROR 401. Then when I restart the server, the REST API will start work again, so it's not about wrong credentials or wrong authentication header.
 I will try to reproduce the issue on another laptop as I described to ensure it's the right approach.

Comment 7 Maciej Swiderski 2013-10-03 12:38:41 UTC
this is caused by bug in AS7/EAP6.1 that is mentioned in following thread https://community.jboss.org/message/822388

Since we relied on PolicyContext to get hold of request we were affected by that bug. Fix that was done for it removed dependency on PolicyContext and thus overcomes the app server bug.

uberfire 
master:
https://github.com/droolsjbpm/uberfire/commit/e1d3fdd4af3b25f68c46ec06af1cc90b244feade

0.3.x
https://github.com/droolsjbpm/uberfire/commit/e03a4dd169e25cf3c12fb41e22451f225f2962af

Comment 8 Ivo Bek 2013-12-04 10:05:46 UTC
I cannot verify this issue with BPMS 6.0.0.ER5 now because of BZ 1035780, and BZ 1035775.

Comment 9 Ivo Bek 2014-01-10 09:14:36 UTC
Verified in BPMS 6.0.0.ER7