[JBoss JIRA] (AS7-2756) Implement username / password strength checks
by Darran Lofthouse (Created) (JIRA)
Implement username / password strength checks
---------------------------------------------
Key: AS7-2756
URL: https://issues.jboss.org/browse/AS7-2756
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Brian Stansberry
Fix For: Open To Community
The AS 7.1 distribution now contains a utility for adding new users to the property files, this utility contains some very basic checks of the username and password e.g. bad choices of username and disallowing passwords which match the username.
This Jira is to implement a more advanced check to enforce complexity.
I believe we should have something along the lines of a util that will take a username and password and will respond ACCEPT, REJECT, or WARN where WARN has a message to display to the user and the user an opportunity to ignore the warning or return to re-entry of the details.
At some point in the future this could become a management operations so the implementation shouldn't be too constrained to the current command line tool.
As a management op we may also want to take into account the user making the request, i.e. a user changing their own password has tighter restrictions than the overall administrator.
As the add user script is currently stand alone this may be a nice task for someone to undertake who would like to get more familiar with submitting an AS change without needing to get too involved with the internals of the application server at this stage.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (AS7-3016) Lazy enlistment of JMS Session does not work - UserTransaction implementation does not support it
by Jiri Pechanec (Created) (JIRA)
Lazy enlistment of JMS Session does not work - UserTransaction implementation does not support it
-------------------------------------------------------------------------------------------------
Key: AS7-3016
URL: https://issues.jboss.org/browse/AS7-3016
Project: Application Server 7
Issue Type: Bug
Components: Transactions
Affects Versions: 7.1.0.Beta1b
Reporter: Jiri Pechanec
Assignee: Jonathan Halliday
Priority: Critical
This test case was identified in TCK6. There is a MDB with CMT configured - com/sun/ts/tests/jms/ee/mdb/xa
The testsuite sends a message to MDB
MDB
1) creates a QueueSession
2) Start UT
3) Send a message
4) Rollback UT
5) Start UT
6) Send a message
7) commit UT
Unfortunately the semantics is broken as QueueSession is not enlisted into transactions.
The enlistment is done when UserTransaction emits a notification org/jboss/tm/usertx/UserTransactionRegistry. The enlistment is done by JCA component which receives the notification and enlists all active XAResources.
Unfortunately the notification is emitted by org/jboss/tm/usertx/client/ServerVMClientUserTransaction. Unfortunately org/jboss/as/txn/service/ArjunaTransactionManagerService hard-codes com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple which does not have this capability.
It is necessary to support this scenario as it is tested in TCKs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] Created: (AS7-1268) Can't update subhandler on async handler
by Stan Silvert (JIRA)
Can't update subhandler on async handler
----------------------------------------
Key: AS7-1268
URL: https://issues.jboss.org/browse/AS7-1268
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.1.0.Alpha1
Reporter: Stan Silvert
Assignee: David Lloyd
David, sorry if I'm assigning to the wrong person. I guess this could be a CLI bug.
[standalone@localhost:9999 /] cd subsystem=logging/async-handler=ASYNC
[standalone@localhost:9999 async-handler=ASYNC] :read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"level" => "INFO",
"overflow-action" => "BLOCK",
"queue-length" => 1024,
"subhandlers" => ["FILE"]
}
}
[standalone@localhost:9999 async-handler=ASYNC] :update-properties(subhandlers=["CONSOLE"])
{"outcome" => "success"}
[standalone@localhost:9999 async-handler=ASYNC] :read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"level" => "INFO",
"overflow-action" => "BLOCK",
"queue-length" => 1024,
"subhandlers" => ["FILE"]
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months