Bug 1104730 - [GSS] add-user.sh exits with status code 0 when password complexity fails
Summary: [GSS] add-user.sh exits with status code 0 when password complexity fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Scripts and Commands
Version: 6.3.0
Hardware: All
OS: All
unspecified
medium
Target Milestone: DR1
: EAP 6.4.0
Assignee: Chao Wang
QA Contact: Petr Kremensky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-04 14:46 UTC by Andy Fraley
Modified: 2019-09-12 07:54 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-3508 0 Minor Resolved add-user.sh exits with status code 0 when password complexity fails 2016-02-02 08:47:44 UTC

Description Andy Fraley 2014-06-04 14:46:35 UTC
Description of problem:
add-user.sh exists with status code 0 when the password complexity check fails.  This should exit with status code 1 instead.

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

How reproducible:
./add-user.sh -u derp -p 1234; echo $?

Actual results:
0

Expected results:
1

Additional info:

Comment 1 Chao Wang 2014-06-09 07:57:10 UTC
IMHO, its not a bug. It works like that by design since we catch the PasswordValidationException which is threw from LengthRestriction, and generate a new ErrorState to print error message into terminal. Due to this, the exit status code is 0.

Comment 2 Andy Fraley 2014-06-11 15:10:46 UTC
The script fails to create the user, so IMO it should exit with an error status.  For example, I'm trying to use this script as part of a Chef recipe that needs to create an admin account.  Due to this behavior, I can't use the exit status of the script to determine if the account creation was successful.

Comment 4 Fernando Nasser 2014-07-09 12:43:09 UTC
A good fix to add on a CPxx release, so I propose 6.3.1 (could not find flag)

Comment 5 Darran Lofthouse 2014-07-09 12:56:43 UTC
If this issue is going to become the issue for EAP 6.3.1 which issue is going to track EAP 6.4.0?  Without an ACKed issue for EAP 6.4.0 I don't believe this can go into EAP 6.3.1 unless we are handling that one differently.

Comment 8 Petr Kremensky 2014-09-19 08:32:49 UTC
Verified on EAP 6.4.0.DR1.1

Comment 9 Shay Matasaro 2015-10-01 13:35:01 UTC
fix requested for next EAP CP


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