[JBoss JIRA] (WFLY-7334) Elytron kerberos implementation ignore java.security.krb5.* system properties
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7334:
-------------------------------
Attachment: standalone-elytron.xml
> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
> Key: WFLY-7334
> URL: https://issues.jboss.org/browse/WFLY-7334
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code}
> -Djava.security.krb5.conf=/unreal/path -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
> <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
> <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
> <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
> <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1302) OOPath ReactiveList remove cases
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1302?page=com.atlassian.jira.plugi... ]
Matteo Mortari edited comment on DROOLS-1302 at 10/20/16 6:30 AM:
------------------------------------------------------------------
As discussed in presence the previous solution in ReactiveList :
{code:java}
@Override
public boolean add(T t) {
boolean result = list.add(t);
ReactiveObjectUtil.notifyModification(t, getLeftTuples(), ModificationType.ADD);
if (t instanceof ReactiveObject) {
for (Tuple lts : getLeftTuples()) {
((ReactiveObject) t).addLeftTuple(lts);
}
}
return result;
}
{code}
is not really ideal as this case fails by creating twice the match:
{code:java}
@Test
public void testMatteo2() {
String drl =
"import org.drools.compiler.xpath.*;\n" +
"global java.util.List list\n" +
"\n" +
"rule R when\n" +
" Man( $usage: /wife/children{age > 10}/toys/usage{level > 10} )\n" +
"then\n" +
" list.add( $usage );\n" +
"end\n";
KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL ).build();
KieSession ksession = kbase.newKieSession();
List<String> list = new ArrayList<String>();
ksession.setGlobal( "list", list );
Woman alice = new Woman( "Alice", 38 );
Man bob = new Man( "Bob", 40 );
bob.setWife( alice );
ksession.insert( bob );
ksession.fireAllRules();
list.clear();
Child eleonor = new Child( "Eleonor", 10 );
alice.addChild( eleonor );
Toy toy = new Toy( "eleonor toy 1" );
eleonor.addToy( toy );
Usage usage = new Usage();
toy.setUsage(usage);
usage.setLevel(0);
eleonor.setAge(11);
ksession.fireAllRules();
System.out.println(list);
usage.setLevel(99);
ksession.fireAllRules();
System.out.println(list);
}
{code}
(removing the first of the 3 fires, does not exhibit the issue, so as discussed this could be related with the fact the from node create the fh twice.)
(having the first setter to usage.setLevel(99); instead of above usage.setLevel(0); would exhibit the issue multiplied, at the 2/3 fired having 2 match, at the 3/3 fired having 4 match)
was (Author: tari_manga):
As discussed in presence the previous solution in ReactiveList :
{code:java}
@Override
public boolean add(T t) {
boolean result = list.add(t);
ReactiveObjectUtil.notifyModification(t, getLeftTuples(), ModificationType.ADD);
if (t instanceof ReactiveObject) {
for (Tuple lts : getLeftTuples()) {
((ReactiveObject) t).addLeftTuple(lts);
}
}
return result;
}
{code}
is not really ideal as this case fails by creating twice the match:
{code:java}
@Test
public void testMatteo2() {
String drl =
"import org.drools.compiler.xpath.*;\n" +
"global java.util.List list\n" +
"\n" +
"rule R when\n" +
" Man( $usage: /wife/children{age > 10}/toys/usage{level > 10} )\n" +
"then\n" +
" list.add( $usage );\n" +
"end\n";
KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL ).build();
KieSession ksession = kbase.newKieSession();
List<String> list = new ArrayList<String>();
ksession.setGlobal( "list", list );
Woman alice = new Woman( "Alice", 38 );
Man bob = new Man( "Bob", 40 );
bob.setWife( alice );
ksession.insert( bob );
ksession.fireAllRules();
list.clear();
Child eleonor = new Child( "Eleonor", 10 );
alice.addChild( eleonor );
Toy toy = new Toy( "eleonor toy 1" );
eleonor.addToy( toy );
Usage usage = new Usage();
toy.setUsage(usage);
usage.setLevel(99);
eleonor.setAge(11);
ksession.fireAllRules();
System.out.println(list);
usage.setLevel(99);
ksession.fireAllRules();
System.out.println(list);
}
{code}
> OOPath ReactiveList remove cases
> --------------------------------
>
> Key: DROOLS-1302
> URL: https://issues.jboss.org/browse/DROOLS-1302
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.CR2
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 7.0.0.Beta2
>
>
> * Removing element from ReactiveList is not covered
> * Ensure removing from 1 out of many ReactiveList does affect only the relevant lists when issuing modification to a ReactiveObject
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1302) OOPath ReactiveList remove cases
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1302?page=com.atlassian.jira.plugi... ]
Matteo Mortari reopened DROOLS-1302:
------------------------------------
Assignee: Mario Fusco (was: Matteo Mortari)
As discussed in presence the previous solution in ReactiveList :
{code:java}
@Override
public boolean add(T t) {
boolean result = list.add(t);
ReactiveObjectUtil.notifyModification(t, getLeftTuples(), ModificationType.ADD);
if (t instanceof ReactiveObject) {
for (Tuple lts : getLeftTuples()) {
((ReactiveObject) t).addLeftTuple(lts);
}
}
return result;
}
{code}
is not really ideal as this case fails by creating twice the match:
{code:java}
@Test
public void testMatteo2() {
String drl =
"import org.drools.compiler.xpath.*;\n" +
"global java.util.List list\n" +
"\n" +
"rule R when\n" +
" Man( $usage: /wife/children{age > 10}/toys/usage{level > 10} )\n" +
"then\n" +
" list.add( $usage );\n" +
"end\n";
KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL ).build();
KieSession ksession = kbase.newKieSession();
List<String> list = new ArrayList<String>();
ksession.setGlobal( "list", list );
Woman alice = new Woman( "Alice", 38 );
Man bob = new Man( "Bob", 40 );
bob.setWife( alice );
ksession.insert( bob );
ksession.fireAllRules();
list.clear();
Child eleonor = new Child( "Eleonor", 10 );
alice.addChild( eleonor );
Toy toy = new Toy( "eleonor toy 1" );
eleonor.addToy( toy );
Usage usage = new Usage();
toy.setUsage(usage);
usage.setLevel(99);
eleonor.setAge(11);
ksession.fireAllRules();
System.out.println(list);
usage.setLevel(99);
ksession.fireAllRules();
System.out.println(list);
}
{code}
> OOPath ReactiveList remove cases
> --------------------------------
>
> Key: DROOLS-1302
> URL: https://issues.jboss.org/browse/DROOLS-1302
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.CR2
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 7.0.0.Beta2
>
>
> * Removing element from ReactiveList is not covered
> * Ensure removing from 1 out of many ReactiveList does affect only the relevant lists when issuing modification to a ReactiveObject
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7334) Elytron kerberos implementation ignore java.security.krb5.* system properties
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7334:
----------------------------------
Would you attach your standalone.xml to reproduce it faster? Thanks
> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
> Key: WFLY-7334
> URL: https://issues.jboss.org/browse/WFLY-7334
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code}
> -Djava.security.krb5.conf=/unreal/path -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
> <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
> <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
> <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
> <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7353) CDI bean-discovery-mode does not default to "annotated"
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-7353?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-7353:
------------------------------------
For the record, the CDI spec states in [12.1. Bean archives|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_archive]:
bq. A bean archive which contains a beans.xml file with version 1.1 (or later) must specify the bean-discovey-mode attribute.
Also the attribute is required in XSD.
> CDI bean-discovery-mode does not default to "annotated"
> -------------------------------------------------------
>
> Key: WFLY-7353
> URL: https://issues.jboss.org/browse/WFLY-7353
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Environment: EAP 7.0.2
> Reporter: Teresa Miyar
> Assignee: Martin Kouba
> Labels: support
> Attachments: demo-war-2.zip
>
>
> bean-discovery-mode does not default to "annotated" when you have a beans.xml version 1.1 without setting the discovery mode. That means that the bean without annotation gets injected.
> To reproduce:
> Download attached war, run into EAP 7.0.2, point browser to demo-war/servlet, check logs
> result:
> I see the log from bean call
> expected result:
> either WFLYCTL0184: New missing/unsatisfied dependencies on startup, or null pointer exception when accessing the servlet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7355) Elytron subsystem requires user to input OIDs
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7355?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6521 to WFLY-7355:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7355 (was: JBEAP-6521)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR6)
> Elytron subsystem requires user to input OIDs
> ---------------------------------------------
>
> Key: WFLY-7355
> URL: https://issues.jboss.org/browse/WFLY-7355
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
>
> On couple of places in elytron subsystem raw oids are expected from user input, e.g. 2.5.4.4 . Is there chance some aliasing could be introduced? So for example human readable "surname" can be used?
> * kerberos-security-factory
> ** mechanism-oids
> * x500-principal-decoder
> ** oid
> ** required-oids
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7355) Elytron subsystem requires user to input OIDs
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7355?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7355:
-------------------------------
Description:
On couple of places in elytron subsystem raw oids are expected from user input, e.g. {{2.5.4.4}} . Is there chance some aliasing could be introduced? So for example human readable {{surname}} can be used?
* kerberos-security-factory
** mechanism-oids
* x500-principal-decoder
** oid
** required-oids
was:
On couple of places in elytron subsystem raw oids are expected from user input, e.g. 2.5.4.4 . Is there chance some aliasing could be introduced? So for example human readable "surname" can be used?
* kerberos-security-factory
** mechanism-oids
* x500-principal-decoder
** oid
** required-oids
> Elytron subsystem requires user to input OIDs
> ---------------------------------------------
>
> Key: WFLY-7355
> URL: https://issues.jboss.org/browse/WFLY-7355
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
>
> On couple of places in elytron subsystem raw oids are expected from user input, e.g. {{2.5.4.4}} . Is there chance some aliasing could be introduced? So for example human readable {{surname}} can be used?
> * kerberos-security-factory
> ** mechanism-oids
> * x500-principal-decoder
> ** oid
> ** required-oids
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7353) CDI bean-discovery-mode does not default to "annotated"
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7353?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7353.
----------------------------------
Resolution: Rejected
See section 2.5 of the CDI spec
> CDI bean-discovery-mode does not default to "annotated"
> -------------------------------------------------------
>
> Key: WFLY-7353
> URL: https://issues.jboss.org/browse/WFLY-7353
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final
> Environment: EAP 7.0.2
> Reporter: Teresa Miyar
> Assignee: Martin Kouba
> Labels: support
> Attachments: demo-war-2.zip
>
>
> bean-discovery-mode does not default to "annotated" when you have a beans.xml version 1.1 without setting the discovery mode. That means that the bean without annotation gets injected.
> To reproduce:
> Download attached war, run into EAP 7.0.2, point browser to demo-war/servlet, check logs
> result:
> I see the log from bean call
> expected result:
> either WFLYCTL0184: New missing/unsatisfied dependencies on startup, or null pointer exception when accessing the servlet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7304) Compensations subsystem
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-7304?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on WFLY-7304:
---------------------------------------
I wasn't aware of such option. I thought that since it's more optional functionality and also enables two services from XTS, it shouldn't be in transactions subsystem.
Is there any documentation or wiki on how to implement the sub-resource?
> Compensations subsystem
> -----------------------
>
> Key: WFLY-7304
> URL: https://issues.jboss.org/browse/WFLY-7304
> Project: WildFly
> Issue Type: Task
> Components: Transactions
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.
> The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months