September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1373) IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1373?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1373: --------------------------------- [~dlofthouse] by javadoc, isEstablished returns true if "no more tokens are needed from the peer" (and negotiating loop should be terminated) Oracle says true = loop should be terminated, we dont suppose more input from client (but srcName obtaining will fail) IBM says false = loop should continue, we suppose client will continue by trying another ticket maybe? I think booth JDKs behaviors can be correct and are OK for us. When reconsidering, the status code 200 is correct for SPNEGO+FORM when invalid token is send and it is not possible to use continuation as NONE scope is used. The status code 401 would be used only when it would be without FORM fallback and it would be send without authenticate response, as continuation is not possible with NONE scope. Elytron behavior is correct - closing. > IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned > ----------------------------------------------------------------------- > > Key: ELY-1373 > URL: https://issues.jboss.org/browse/ELY-1373 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Beta3 > Reporter: Jan Kalina > Assignee: Jan Kalina > > Given SPNEGO + FORM authentication configuration. And running on IBM java. > When invalid kerberos ticket is send > Then status code 200 is returned with http form. > While on Oracle JDK {{gssContext.isEstablished()}} returns true for invalid client ticket (negotiate with wrong domain JBOSS.COM), so SPNEGO mechanism sends bare challenge after failed authorization, on IBM JDK it returns false immediately, so mechanism fail without sending challenge - to be consistent should be send in both cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1373) IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1373?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1373: ---------------------------- Description: Given SPNEGO + FORM authentication configuration. And running on IBM java. When invalid kerberos ticket is send Then status code 200 is returned with http form. While on Oracle JDK {{gssContext.isEstablished()}} returns true for invalid client ticket (negotiate with wrong domain JBOSS.COM), so SPNEGO mechanism sends bare challenge after failed authorization, on IBM JDK it returns false immediately, so mechanism fail without sending challenge - to be consistent should be send in both cases. was: Given SPNEGO + FORM authentication configuration. And running on IBM java. When invalid kerberos ticket is send Then status code 200 is returned with http form. While on Oracle JDK {{gssContext.isEstablished()}} returns true for invalid client ticket, so SPNEGO mechanism send bare challenge after failed authorization, on IBM JDK it returns false immediately, so mechanism fail without sending challenge - to be consistent should be send in both cases. > IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned > ----------------------------------------------------------------------- > > Key: ELY-1373 > URL: https://issues.jboss.org/browse/ELY-1373 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Beta3 > Reporter: Jan Kalina > Assignee: Jan Kalina > > Given SPNEGO + FORM authentication configuration. And running on IBM java. > When invalid kerberos ticket is send > Then status code 200 is returned with http form. > While on Oracle JDK {{gssContext.isEstablished()}} returns true for invalid client ticket (negotiate with wrong domain JBOSS.COM), so SPNEGO mechanism sends bare challenge after failed authorization, on IBM JDK it returns false immediately, so mechanism fail without sending challenge - to be consistent should be send in both cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes

by Martin Stefanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ] Martin Stefanko edited comment on WFCORE-3316 at 9/25/17 5:51 AM: ------------------------------------------------------------------ [~jdenise] value validator is not actually checking the allowed values on addition of the attribute, I've already got fix in progress [~dlofthouse] thanks, in that case it should be remoting subsytem was (Author: mstefank): [~jdenise] value validator is not actually checking the allowed values on addition of the attribute, I've already got fix in progress > Server fails to start after submitting invalid security attributes > ------------------------------------------------------------------ > > Key: WFCORE-3316 > URL: https://issues.jboss.org/browse/WFCORE-3316 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 3.0.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > > Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength) > Only fix for the configuration is to manually change the XML file directly -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes

by Martin Stefanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ] Martin Stefanko commented on WFCORE-3316: ----------------------------------------- [~jdenise] value validator is not actually checking the allowed values on addition of the attribute, I've already got fix in progress > Server fails to start after submitting invalid security attributes > ------------------------------------------------------------------ > > Key: WFCORE-3316 > URL: https://issues.jboss.org/browse/WFCORE-3316 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 3.0.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > > Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength) > Only fix for the configuration is to manually change the XML file directly -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-3316: ------------------------------------------ Have changed the component to 'Remoting' as this is specifically an issue within the remoting subsystem. Issues like this are almost never CLI related, the CLI is just the client side tool to interact with the management model but the validation of that model happens within the subsystem server side. > Server fails to start after submitting invalid security attributes > ------------------------------------------------------------------ > > Key: WFCORE-3316 > URL: https://issues.jboss.org/browse/WFCORE-3316 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 3.0.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > > Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength) > Only fix for the configuration is to manually change the XML file directly -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-3316: ------------------------------------- Component/s: Remoting (was: CLI) > Server fails to start after submitting invalid security attributes > ------------------------------------------------------------------ > > Key: WFCORE-3316 > URL: https://issues.jboss.org/browse/WFCORE-3316 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Affects Versions: 3.0.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > > Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength) > Only fix for the configuration is to manually change the XML file directly -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1373) IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1373?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1373: ---------------------------- Steps to Reproduce: {code} git clone git@gitlab.mw.lab.eng.bos.redhat.com:mchoma/tests-ldap-kerberos.git cd tests-ldap-kerberos git checkout 7.x JAVA_HOME=/opt/ibm-java-x86_64-80 ./build-eap71.sh -Dversion.jboss.bom=7.1.0.GA -Dversion.wildfly.core=4.0.0.Alpha1-SNAPSHOT -Djboss.dist.zip=/home/jkalina/work/wildfly/build/target/wildfly-11.0.0.Final-SNAPSHOT.zip -Dtest=SPNEGONoneTestCase#testInvalidTicketFormFallback {code} was: {code} git clone git@gitlab.mw.lab.eng.bos.redhat.com:mchoma/tests-ldap-kerberos.git cd tests-ldap-kerberos git checkout 7.x ./build-eap71.sh -Dversion.jboss.bom=7.1.0.GA -Dversion.wildfly.core=3.0.1.Final-redhat-1 -Dmaven.repo.local=/home/mchoma/workspace/eap-versions/7.1.0.CR1/jboss-eap-7.1.0.GA-maven-repository/maven-repository -Djboss.dist.zip=/home/mchoma/workspace/eap-versions/7.1.0.CR1/jboss-eap-7.1.0.CR1.zip -Dmaven.test.failure.ignore=true -Dignore.known.issues=true -Dtest=SPNEGONoneTestCase#testInvalidTicketFormFallback {code} > IBM JDK, SPNEGO + FORM; with invalid ticket 200 status code is returned > ----------------------------------------------------------------------- > > Key: ELY-1373 > URL: https://issues.jboss.org/browse/ELY-1373 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Beta3 > Reporter: Jan Kalina > Assignee: Jan Kalina > > Given SPNEGO + FORM authentication configuration. And running on IBM java. > When invalid kerberos ticket is send > Then status code 200 is returned with http form. > While on Oracle JDK {{gssContext.isEstablished()}} returns true for invalid client ticket, so SPNEGO mechanism send bare challenge after failed authorization, on IBM JDK it returns false immediately, so mechanism fail without sending challenge - to be consistent should be send in both cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1742) NPE in RuleNEtworkEvaluator after incremental compilation

by Théophane Charbonnier (JIRA)

Théophane Charbonnier created DROOLS-1742: --------------------------------------------- Summary: NPE in RuleNEtworkEvaluator after incremental compilation Key: DROOLS-1742 URL: https://issues.jboss.org/browse/DROOLS-1742 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.3.0.Final Reporter: Théophane Charbonnier Assignee: Mario Fusco Attachments: drools-path-memory-reproducer.zip Having the following drl files : {code:drl} package org.hightea.a import org.drools.compiler.Message import org.drools.compiler.FirstClass rule "RG_1" when $event : Message() FirstClass(item1 == $event.message1) then System.out.println("RG_1"); end {code} and {code:drl} package org.hightea.b import org.drools.compiler.Message import org.drools.compiler.SecondClass rule "RG_2" when $event: Message() SecondClass(item1 == $event.message1) then System.out.println("RG_2"); end {code} We create a module containing the two packages in two drl files and insert a `SecondClass` fact in the WM. Then we want to incrementally update to a new module containing only the second DRL. At first fireAllrules after update, we encounter a NPE in RuleNetwork evaluator (a Segment memory is not defined in the path memory) {code:java} java.lang.NullPointerException at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:114) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87) at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34) at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067) at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006) at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295) at org.hightea.IncrementalRemoveRuleTest.testNpeInRuleNetworkEvaluator(IncrementalRemoveRuleTest.java:66) {code} Note that we don't encounter this issue when the packages names are the same, or if we exchange the order of drl file name in the first module. A reproducer is attached with its source code at [https://github.com/hightea/drools-reproducer/tree/path-memory-issue|https...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3316) Server fails to start after submitting invalid security attributes

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3316?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3316: ---------------------------------------------- [~mstefank], is that a CLI issue? Seems a server side issue? > Server fails to start after submitting invalid security attributes > ------------------------------------------------------------------ > > Key: WFCORE-3316 > URL: https://issues.jboss.org/browse/WFCORE-3316 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > > Server fails to start after submitting invalid security attributes values for remoting http connector (e.g QOP, strength) > Only fix for the configuration is to manually change the XML file directly -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9375) META-INF/services are always accessible from dependencies

by Alexander Kudrevatykh (JIRA)

[ https://issues.jboss.org/browse/WFLY-9375?page=com.atlassian.jira.plugin.... ] Alexander Kudrevatykh commented on WFLY-9375: --------------------------------------------- Also I found question https://developer.jboss.org/thread/275394 that can be caused by this issue > META-INF/services are always accessible from dependencies > --------------------------------------------------------- > > Key: WFLY-9375 > URL: https://issues.jboss.org/browse/WFLY-9375 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final, 10.1.0.Final, 11.0.0.CR1 > Reporter: Alexander Kudrevatykh > Assignee: Jason Greene > > I found regression in Wildfly 10.1 (10.0 and 11 CR1 also affected) - META-INF/services entries are accesible from war dependencies, even if not marked as "import" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2017