[JBoss JIRA] (ELY-1455) DB query seen for each request using FORM mechanism.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1455:
---------------------------------------
+1 If you update the login page so it's submission is compatible with the Servlet specification defined FORM authentication mechanism then this mechanism will take over the authentication including the storage of the resulting SecurityIdentity for use on subsequent requests, here is an example of a simple FORM: -
{code}
<html>
<head>
<title>Login Page</title>
</head>
<body>
<font size='5' color='blue'>Please Login</font><hr>
<form action='j_security_check' method='post'>
<table>
<tr><td>Name:</td>
<td><input type='text' name='j_username'></td></tr>
<tr><td>Password:</td>
<td><input type='password' name='j_password' size='8'></td>
</tr>
</table>
<br>
<input type='submit' value='login'>
</form>
</body>
</html>
{code}
Note: The action AND the two input fields are required to use 'j_security_check', 'j_username', 'j_password' need to use respectively.
> DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
> Key: ELY-1455
> URL: https://issues.jboss.org/browse/ELY-1455
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 1.2.0.Beta11
>
> Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request.
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
> <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
> <attribute-mapping>
> <attribute to="Roles" index="1"/>
> </attribute-mapping>
> <simple-digest-mapper password-index="2"/>
> </principal-query>
> </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (DROOLS-2165) Upgrade revapi-maven-plugin from 0.9.4 to 0.9.5
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2165?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer commented on DROOLS-2165:
------------------------------------------------
[~ge0ffrey] i suppose on master and on 7.5.x ?
> Upgrade revapi-maven-plugin from 0.9.4 to 0.9.5
> -----------------------------------------------
>
> Key: DROOLS-2165
> URL: https://issues.jboss.org/browse/DROOLS-2165
> Project: Drools
> Issue Type: Task
> Components: build
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
>
> It's a good thing to just do,
> but hopefully this message goes away on the jenkins job for drools:
> {code}
> 09:33:13 [INFO] ------------------------------------------------------------------------
> 09:33:13 [INFO] Building KIE :: Maven Archetypes 7.6.0-SNAPSHOT
> 09:33:13 [INFO] ------------------------------------------------------------------------
> 09:33:13 [WARNING] *****************************************************************
> 09:33:13 [WARNING] * Your build is requesting parallel execution, but project *
> 09:33:13 [WARNING] * contains the following plugin(s) that have goals not marked *
> 09:33:13 [WARNING] * as @threadSafe to support parallel building. *
> 09:33:13 [WARNING] * While this /may/ work fine, please look for plugin updates *
> 09:33:13 [WARNING] * and/or request plugins be made thread-safe. *
> 09:33:13 [WARNING] * If reporting an issue, report it against the plugin in *
> 09:33:13 [WARNING] * question, not against maven-core *
> 09:33:13 [WARNING] *****************************************************************
> 09:33:13 [WARNING] The following plugins are not marked @threadSafe in KIE :: Public API:
> 09:33:13 [WARNING] org.revapi:revapi-maven-plugin:0.9.4
> 09:33:13 [WARNING] Enable debug to see more precisely which goals are not marked @threadSafe.
> 09:33:13 [WARNING] *****************************************************************
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (ELY-1455) DB query seen for each request using FORM mechanism.
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Martin Choma edited comment on ELY-1455 at 12/7/17 4:59 AM:
------------------------------------------------------------
You should use j_security_check in conjuction with FORM per se.
{quote}
In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check.
{quote}
You can use BASIC. Or if you want login form authentication you are probably left to fully application handling in that case.
[1] http://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/serv...
was (Author: mchoma):
You should use j_security_check in conjuction with FORM per se.
{quote}
In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check.
{quote}
You can use BASIC. Or if you want FORM authentication you are probably left to fully application handling.
[1] http://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/serv...
> DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
> Key: ELY-1455
> URL: https://issues.jboss.org/browse/ELY-1455
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 1.2.0.Beta11
>
> Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request.
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
> <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
> <attribute-mapping>
> <attribute to="Roles" index="1"/>
> </attribute-mapping>
> <simple-digest-mapper password-index="2"/>
> </principal-query>
> </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (ELY-1455) DB query seen for each request using FORM mechanism.
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1455:
-----------------------------------
You should use j_security_check in conjuction with FORM per se.
{quote}
In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check.
{quote}
You can use BASIC. Or if you want FORM authentication you are probably left to fully application handling.
[1] http://download.oracle.com/otn-pub/jcp/servlet-3.0-fr-eval-oth-JSpec/serv...
> DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
> Key: ELY-1455
> URL: https://issues.jboss.org/browse/ELY-1455
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 1.2.0.Beta11
>
> Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request.
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
> <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
> <attribute-mapping>
> <attribute to="Roles" index="1"/>
> </attribute-mapping>
> <simple-digest-mapper password-index="2"/>
> </principal-query>
> </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Harald Pehl commented on WFCORE-887:
------------------------------------
Cool. Glad to see that the tool is useful after all ;-)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Alpha5
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We use INFO messages for other management API deprecation messages, but these I believe deserve a WARN. The issue here isn't just that we may change something in the future (seen as not justifying a WARN) but also that the capability/requirement bookkeeping for the attribute cannot be properly done if an expression is used, meaning the model integrity behavior meant to be in place cannot be used.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-6880) Disable slow client reconnecting with KILL slow client policy
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6880?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6880:
--------------------------------------
Hi [~bayern39], it seems that this feature was implemented in Artemis 1.4. WF11 contain Artemis 1.5.5 and this should be solved there. Can this feature request be resolved?
> Disable slow client reconnecting with KILL slow client policy
> --------------------------------------------------------------
>
> Key: WFLY-6880
> URL: https://issues.jboss.org/browse/WFLY-6880
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
> Priority: Minor
>
> It is possible to detect and handle(KILL, NOTIFY) slow consumers. In case policy KILL is used and connection factory used to create connection of slow consumer has attribute {{reconnect-attempts}} set to {{"-1"}}, slow consumer reconnects to server. This consumer is then reconnects, is detected as slow and disconnected.
> Attribute {{reconnect-attempts="-1"}} should be ignored, and slow client should not be trying to reconnect once it is disconnected by KILL slow consumer policy.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3450:
----------------------------------------------
I have added the following note in help: https://github.com/wildfly/wildfly-core/pull/2976
> CLI - avoid required attributes to be hard to see when using tab completion
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3450
> URL: https://issues.jboss.org/browse/WFCORE-3450
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Miroslav Novak
>
> This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add(
> ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier
> allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors*
> call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection
> call-timeout connection-ttl max-hops notification-attempts retry-interval
> {code}
> it's not clear at the first look how many required attributes there are.
> Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>.
> Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3450) CLI - avoid required attributes to be hard to see when using tab completion
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3450:
----------------------------------------------
[~iweiss], you made a point related to documentation, we need to document that '*' means required. I will add a note in the cli help. This should have been done first place.
Coloured CLI would be something to discuss. As soon as we choose some colours, we would have people liking them and other not liking. Making colours configurable seems a bit too much to me. Colours are also not interpreted the same way on various platforms, so colouring should be adapted per platform. Personally I don't think that coloured terminal is helpful, I much prefer back and white. bold could be a good alternative for required attributes.
BTW, Aesh already supports that by the mean of ANSI. I remember that [~ehugonnet] did some prototyping to colour operation failure in red.
> CLI - avoid required attributes to be hard to see when using tab completion
> ----------------------------------------------------------------------------
>
> Key: WFCORE-3450
> URL: https://issues.jboss.org/browse/WFCORE-3450
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Miroslav Novak
>
> This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in:
> {code}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add(
> ! check-period connector-name* max-retry-interval notification-interval retry-interval-multiplier
> allow-direct-connections-only cluster-connection-address* discovery-group* message-load-balancing-type producer-window-size static-connectors*
> call-failover-timeout confirmation-window-size initial-connect-attempts min-large-message-size reconnect-attempts use-duplicate-detection
> call-timeout connection-ttl max-hops notification-attempts retry-interval
> {code}
> it's not clear at the first look how many required attributes there are.
> Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>.
> Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watc...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (ELY-1455) DB query seen for each request using FORM mechanism.
by Alberto Gori (JIRA)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Alberto Gori edited comment on ELY-1455 at 12/7/17 3:29 AM:
------------------------------------------------------------
Thanks for explanation. I am not sure I understood it completely, though.
Is it incorrect to declare a FORM authentication and use programmatic API instead? If so, what am I supposed to declare in auth-method tag in web.xml if I want to stick to programmatic API?
Or you were saying that this configuration is hitting a bug in elytron/wildfly?
Anyway, I think I'll go for option 2 (if FORM + API is ok).
Also, are these bugs related to SSO (that is not working at all)?
was (Author: lagoria):
Thanks for explanation. I am not sure I understood it completely.
Is it incorrect to declare a FORM authentication and use programmatic API instead? If so, what am I supposed to declare in auth-method tag in web.xml if I want to stick to programmatic API?
Or you were saying that this configuration is hitting a bug in elytron/wildfly?
Anyway, I think I'll go for option 2 (if FORM + API is ok).
Also, are these bugs related to SSO (that is not working at all)?
> DB query seen for each request using FORM mechanism.
> -----------------------------------------------------
>
> Key: ELY-1455
> URL: https://issues.jboss.org/browse/ELY-1455
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Fix For: 1.2.0.Beta11
>
> Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request.
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
> <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
> <attribute-mapping>
> <attribute to="Roles" index="1"/>
> </attribute-mapping>
> <simple-digest-mapper password-index="2"/>
> </principal-query>
> </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months