[jboss-jira] [JBoss JIRA] (WFLY-3340) Authentication "module-options" inconsistently hash vs list of key/values

[Chris Pitman (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12967324#comment-12967324 ] 

Chris Pitman commented on WFLY-3340:
------------------------------------

A resolution to 3339 would likely also resolve this issue, since key-value pairs do not exist in most standard formats.

> Authentication "module-options" inconsistently hash vs list of key/values
> -------------------------------------------------------------------------
>
>                 Key: WFLY-3340
>                 URL: https://issues.jboss.org/browse/WFLY-3340
>             Project: WildFly
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: CLI
>    Affects Versions: JBoss AS7 7.1.1.Final
>         Environment: RHEL 6.4, x86_64
>            Reporter: Chris Pitman
>            Assignee: Alexey Loubyansky
>              Labels: automation, cli, configuration_management
>
> When adding an authentication mechanism to a security domain it is possible to set the module-options with a hash (which is great!). However, as soon as a reload occurs they revert back into a list of key-value pairs. This only makes sense if order matters (which I hope it doesn't) or if keys can be repeated (again, hope not).
> Configuration management tools should only change a value when it needs to, and this is way easier if the value that is set is the same value that is read. Hashes are also far easier to work with in ruby/puppet/chef.
> Steps to reproduce:
> 1. Set the module_options on an already existing authentication mechanism:
> {code}
> /subsystem=security/security-domain=servlet-security-quickstart/authentication=classic:write-attribute(name=login-modules, value=[{"code" => "Database","flag"=>"required","module-options"=>{"dsJndiName" =>
> "java:jboss/datasources/ServletSecurityDS", "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?", "role
> sQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"}}])
> {code}
> 2. Read the resource (notice that module-options is till a nice easy to use hash!)
> {code}
> {
>     "outcome" => "success",
>     "result" => {"login-modules" => [{
>         "module-options" => {
>             "dsJndiName" => "java:jboss/datasources/ServletSecurityDS",
>             "principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?",
>             "rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?"
>         },
>         "flag" => "required",
>         "code" => "Database"
>     }]},
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> 3. Reload, then read-resource
> {code}
> {
>     "outcome" => "success",
>     "result" => {"login-modules" => [{
>         "code" => "Database",
>         "flag" => "required",
>         "module-options" => [
>             ("dsJndiName" => "java:jboss/datasources/ServletSecurityDS"),
>             ("principalsQuery" => "SELECT PASSWORD FROM USERS WHERE USERNAME = ?"),
>             ("rolesQuery" => "SELECT R.NAME, 'Roles' FROM USERS_ROLES UR INNER JOIN ROLES R ON R.ID = UR.ROLE_ID INNER JOIN USERS U ON U.ID = UR.USER_ID WHERE U.USERNAME = ?")
>         ]
>     }]}
> }
> {code}
> 4. module-options is now a list of key-value pairs, and is not equal to what it was set to before



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)