[JBoss JIRA] (ELY-457) SASL SAML Authentication Mechanism
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-457?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-457:
---------------------------
Comment: was deleted
(was: Sorry, edit: I has bad understood the RFC, the IdP sends authentication statement to the browser/sasl client, which sends it into sasl sever over sasl. There should be no problem in such case...
{panel}
in the form of an authentication statement or failure, using an indirect response via the client browser or the handler (and with an external browser, client control should be passed back to the SASL client).
{panel})
> SASL SAML Authentication Mechanism
> ----------------------------------
>
> Key: ELY-457
> URL: https://issues.jboss.org/browse/ELY-457
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> https://tools.ietf.org/html/rfc6595
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3440) CLI incorrectly parses byte literals
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3440?page=com.atlassian.jira.plugi... ]
Tomas Hofman updated WFCORE-3440:
---------------------------------
Description:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
was:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
{code}
> CLI incorrectly parses byte literals
> -------------------------------------
>
> Key: WFCORE-3440
> URL: https://issues.jboss.org/browse/WFCORE-3440
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha3
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> * Deploy two deployments,
> * read content hashes of the deployments,
> * try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
> The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
> {code}
> [standalone@localhost:9990 /] /deployment=*:read-resource
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [("deployment" => "FilterServlet.war")],
> "outcome" => "success",
> "result" => {
> "content" => [{
> "hash" => bytes {
> 0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
> 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
> 0x97, 0xed, 0x09, 0x33
> },
> "archive" => undefined
> }],
> ...
> }
> }, ...
> ]
> }
> [standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
> Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3440) CLI incorrectly parses byte literals
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3440?page=com.atlassian.jira.plugi... ]
Tomas Hofman updated WFCORE-3440:
---------------------------------
Description:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
{code}
was:
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
> CLI incorrectly parses byte literals
> -------------------------------------
>
> Key: WFCORE-3440
> URL: https://issues.jboss.org/browse/WFCORE-3440
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha3
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> * Deploy two deployments,
> * read content hashes of the deployments,
> * try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
> The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
> {code}
> [standalone@localhost:9990 /] /deployment=*:read-resource
> {
> "outcome" => "success",
> "result" => [
> {
> "address" => [("deployment" => "FilterServlet.war")],
> "outcome" => "success",
> "result" => {
> "content" => [{
> "hash" => bytes {
> 0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
> 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
> 0x97, 0xed, 0x09, 0x33
> },
> "archive" => undefined
> }],
> ...
> }
> }, ...
> ]
> }
> [standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
> Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3440) CLI incorrectly parses byte literals
by Tomas Hofman (JIRA)
Tomas Hofman created WFCORE-3440:
------------------------------------
Summary: CLI incorrectly parses byte literals
Key: WFCORE-3440
URL: https://issues.jboss.org/browse/WFCORE-3440
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 4.0.0.Alpha3
Reporter: Tomas Hofman
Assignee: Tomas Hofman
* Deploy two deployments,
* read content hashes of the deployments,
* try to {{:full-replace-deployment}} the first deployment with the content hash of the other one (or any made up content hash for that matter).
The byte values of the content hash are not parsed correctly - whenever there's a value larger than 0x7f (e.g. 0xef), the parsing fails with "Value out of range. Value:"ef" Radix:16".
{code}
[standalone@localhost:9990 /] /deployment=*:read-resource
{
"outcome" => "success",
"result" => [
{
"address" => [("deployment" => "FilterServlet.war")],
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3,
0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8,
0x97, 0xed, 0x09, 0x33
},
"archive" => undefined
}],
...
}
}, ...
]
}
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
Failed to parse '[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}]': Value out of range. Value:"ef" Radix:16
[standalone@localhost:9990 /] :full-replace-deployment(name=FilterServlet.war, content=[{hash=bytes{0xef, 0x4c, 0x32, 0x78, 0xd6, 0xc6, 0x01, 0xa3, 0x64, 0xb4, 0xad, 0x73, 0x86, 0x8c, 0x69, 0xa8, 0x97, 0xed, 0x09, 0x33}}])
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9585?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski reassigned WFLY-9585:
------------------------------------
Assignee: Tomasz Adamski
> Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name
> ----------------------------------------------------------
>
> Key: WFLY-9585
> URL: https://issues.jboss.org/browse/WFLY-9585
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga)
> Reporter: Shing Lam
> Assignee: Tomasz Adamski
> Labels: Wildfly-10.0.0.Final, datasource, default, jboss-ejb3.xml, lookup-name, resource-ref
>
> We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used. But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected.
> We have in the ejb-jar.xml
> {code:xml}
> <enterprise-beans>
> <session>
> <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
> <resource-ref>
> <res-ref-name>jdbc/RMDataSource</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <res-auth>Container</res-auth>
> </resource-ref>
> <persistence-context-ref>
> <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name>
> </persistence-context-ref>
> </session>
> {code}
> and in jboss-ejb3.xml
> {code:xml}
> <jboss:enterprise-beans>
> <jboss:ejb>
> <ejb-name>BackgroundRecoverySessionEJB</ejb-name>
> <resource-ref>
> <res-ref-name>jdbc/RMDataSource</res-ref-name>
> <res-type>javax.sql.DataSource</res-type>
> <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name>
> </resource-ref>
> </jboss:ejb>
> {code}
> the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4.
> But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;"
> If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB.
> Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9582) server not starting from windows service
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9582?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-9582.
-----------------------------
Resolution: Rejected
Too little information to tell what is going on.
First try with WildFly 11 and if problem still persist reopen this with all enviroment information and how you configured you startup settings.
> server not starting from windows service
> ----------------------------------------
>
> Key: WFLY-9582
> URL: https://issues.jboss.org/browse/WFLY-9582
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.2.Final
> Environment: Window 7 64-bit system
> Reporter: Roshan Royal
> Assignee: Tomaz Cerar
> Priority: Blocker
>
> Getting below error while trying to start server through windows service.
> [2017-11-29 14:24:47] [info] [14908] Commons Daemon procrun (1.0.15.0 64-bit) started
> [2017-11-29 14:24:47] [info] [14908] Starting service 'Wildfly' ...
> [2017-11-29 14:24:47] [info] [ 3760] Commons Daemon procrun (1.0.15.0 64-bit) started
> [2017-11-29 14:24:47] [info] [ 3760] Running 'Wildfly' Service...
> [2017-11-29 14:24:47] [info] [15500] Starting service...
> [2017-11-29 14:24:47] [info] [15500] Service started in 3 ms.
> [2017-11-29 14:24:47] [info] [ 3760] Run service finished.
> [2017-11-29 14:24:47] [info] [ 3760] Commons Daemon procrun finished
> [2017-11-29 14:24:48] [error] [14908] Failed to start 'Wildfly' service
> [2017-11-29 14:24:48] [error] [14908] The data area passed to a system call is too small.
> [2017-11-29 14:24:48] [info] [14908] Start service finished.
> [2017-11-29 14:24:48] [error] [14908] Commons Daemon procrun failed with exit value: 5 (Failed to start service)
> [2017-11-29 14:24:48] [error] [14908] The data area passed to a system call is too small.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-1805) Guided Decision table not opening
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1805?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-1805:
-------------------------------------
[~ashokrm] I uploaded the table that works, you can't have empty line between table definition row and table data row, it means no empty line after row 8.
[~manstis] please correct me if I am wrong.
> Guided Decision table not opening
> ---------------------------------
>
> Key: DROOLS-1805
> URL: https://issues.jboss.org/browse/DROOLS-1805
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.0.0.Beta6
> Environment: Windows 7. Tomcat 7. JDK 1.8.
> Reporter: Ashok Murugesan
> Assignee: Jozef Marko
> Fix For: 7.5.0.Final
>
> Attachments: Esg-Qual-Ratings-DecisionTableV1 (1).xls, Esg-Qual-Ratings-DecisionTableV1-updated.xls
>
>
> I am trying to convert existing XLS decision table to Guided Decision table in this new version. I validated XLS decision table and it's successful. I converted XLS into Guided Decision table and it's converted successfully. But when I try to open the Guided decision table it throws below error:
> Unable to complete your request. The following exception occurred: Parameter named 'columnTitle' should be not null!.
> Not sure why this issue occurs. Please clarify
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-1805) Guided Decision table not opening
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1805?page=com.atlassian.jira.plugi... ]
Jozef Marko closed DROOLS-1805.
-------------------------------
Fix Version/s: 7.5.0.Final
Resolution: Cannot Reproduce Bug
> Guided Decision table not opening
> ---------------------------------
>
> Key: DROOLS-1805
> URL: https://issues.jboss.org/browse/DROOLS-1805
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.0.0.Beta6
> Environment: Windows 7. Tomcat 7. JDK 1.8.
> Reporter: Ashok Murugesan
> Assignee: Jozef Marko
> Fix For: 7.5.0.Final
>
> Attachments: Esg-Qual-Ratings-DecisionTableV1 (1).xls, Esg-Qual-Ratings-DecisionTableV1-updated.xls
>
>
> I am trying to convert existing XLS decision table to Guided Decision table in this new version. I validated XLS decision table and it's successful. I converted XLS into Guided Decision table and it's converted successfully. But when I try to open the Guided decision table it throws below error:
> Unable to complete your request. The following exception occurred: Parameter named 'columnTitle' should be not null!.
> Not sure why this issue occurs. Please clarify
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (DROOLS-1805) Guided Decision table not opening
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1805?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-1805:
--------------------------------
Attachment: Esg-Qual-Ratings-DecisionTableV1-updated.xls
> Guided Decision table not opening
> ---------------------------------
>
> Key: DROOLS-1805
> URL: https://issues.jboss.org/browse/DROOLS-1805
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.0.0.Beta6
> Environment: Windows 7. Tomcat 7. JDK 1.8.
> Reporter: Ashok Murugesan
> Assignee: Jozef Marko
> Attachments: Esg-Qual-Ratings-DecisionTableV1 (1).xls, Esg-Qual-Ratings-DecisionTableV1-updated.xls
>
>
> I am trying to convert existing XLS decision table to Guided Decision table in this new version. I validated XLS decision table and it's successful. I converted XLS into Guided Decision table and it's converted successfully. But when I try to open the Guided decision table it throws below error:
> Unable to complete your request. The following exception occurred: Parameter named 'columnTitle' should be not null!.
> Not sure why this issue occurs. Please clarify
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 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 commented on ELY-1455:
-----------------------------------
Also, I'd like to add that if I switch to legacy security subsystem, everything works like a charm.
> 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
> Fix For: 1.2.0.Beta11
>
> Attachments: 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, 5 months