March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-715) SPNEGO: missing negState field in the first reply

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-715: -------------------------------- Note: this issue cover "Defective token" (which cannot be parsed and gssContext throws GSSException), but not "Invalid token" (which is expired for example and gssContext returns srcName = null) > SPNEGO: missing negState field in the first reply > ------------------------------------------------- > > Key: ELY-715 > URL: https://issues.jboss.org/browse/ELY-715 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 1.1.0.CR2 > > > When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}. > As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply: > {code:borderStyle=dashed} > negState > ... > This field is REQUIRED in the first reply from the target, and is > OPTIONAL thereafter. When negState is absent, the actual state > should be inferred from the state of the negotiated mechanism > context. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-715) SPNEGO: missing negState field in the first reply

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-715: ------------------------------ Assignee: Darran Lofthouse (was: Jan Kalina) > SPNEGO: missing negState field in the first reply > ------------------------------------------------- > > Key: ELY-715 > URL: https://issues.jboss.org/browse/ELY-715 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR2 > > > When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}. > As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply: > {code:borderStyle=dashed} > negState > ... > This field is REQUIRED in the first reply from the target, and is > OPTIONAL thereafter. When negState is absent, the actual state > should be inferred from the state of the negotiated mechanism > context. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-715) SPNEGO: missing negState field in the first reply

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-715: --------------------------- Comment: was deleted (was: Sorry, it looks I was wrong... >From *testInvalidKerberosSpnegoWorkflow* in tests-ldap-kerberos dubugging results GSSContext provides negState response, but we dont use it if connection is already established (=no continuation is needed). Reopening, working on fix.) > SPNEGO: missing negState field in the first reply > ------------------------------------------------- > > Key: ELY-715 > URL: https://issues.jboss.org/browse/ELY-715 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 1.1.0.CR2 > > > When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}. > As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply: > {code:borderStyle=dashed} > negState > ... > This field is REQUIRED in the first reply from the target, and is > OPTIONAL thereafter. When negState is absent, the actual state > should be inferred from the state of the negotiated mechanism > context. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-715) SPNEGO: missing negState field in the first reply

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-715: --------------------------- Summary: SPNEGO: missing negState field in the first reply (was: SPNEGO: missing negstat field in the first reply) > SPNEGO: missing negState field in the first reply > ------------------------------------------------- > > Key: ELY-715 > URL: https://issues.jboss.org/browse/ELY-715 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 1.1.0.CR2 > > > When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}. > As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply: > {code:borderStyle=dashed} > negState > ... > This field is REQUIRED in the first reply from the target, and is > OPTIONAL thereafter. When negState is absent, the actual state > should be inferred from the state of the negotiated mechanism > context. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-715) SPNEGO: missing negstat field in the first reply

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-715?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reopened ELY-715: ---------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) Sorry, it looks I was wrong... >From *testInvalidKerberosSpnegoWorkflow* in tests-ldap-kerberos dubugging results GSSContext provides negState response, but we dont use it if connection is already established (=no continuation is needed). Reopening, working on fix. > SPNEGO: missing negstat field in the first reply > ------------------------------------------------ > > Key: ELY-715 > URL: https://issues.jboss.org/browse/ELY-715 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 1.1.0.CR2 > > > When the client sends an initial SPNEGO token with Kerberos as preferred mechanism and includes an invalid kerberos token, then client expects to see the {{WWW-Authenticate}} HTTP header with SPNEGO response {{negTokenResp[ negState = reject ]}}. > As stated in [SPNEGO specification|https://tools.ietf.org/html/rfc4178#section-4.2.2] negstat is required in first reply: > {code:borderStyle=dashed} > negState > ... > This field is REQUIRED in the first reply from the target, and is > OPTIONAL thereafter. When negState is absent, the actual state > should be inferred from the state of the negotiated mechanism > context. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2388) DMN Namespace unmarshalling differs from standard one when calling DMNValidator.validate method with File param

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2388?page=com.atlassian.jira.plugi... ] Tibor Zimányi edited comment on DROOLS-2388 at 3/20/18 12:11 PM: ----------------------------------------------------------------- Steps to reproduce: 1. Checkout branch from this PR [1] 2. Change getLocalPart() on this line to toString() [2] 3. Run test [3] 4. Run test [4] Test from point 3. fails on validation error, because the validation rule fired - the typeRef from the provided Definitions contains namespace. However test from point 4. pass, because unmarshalling used in the validate method that takes Reader as an input works differently and doesn't fill namespace in the typeref. This is inconsistent, because a user could expect that the validate methods behave the same when the same file is used (either for getting Definitions or providing it directly to the validate method). [1] https://github.com/kiegroup/drools/pull/1810 [2] https://github.com/baldimir/drools/blob/5a9cb6f09a52cdc46b7cafb52cf615f88... [3] https://github.com/baldimir/drools/blob/7a2c6374351d57011ae67d4fc28900ea8... [4] https://github.com/baldimir/drools/blob/7a2c6374351d57011ae67d4fc28900ea8... was (Author: tzimanyi): Steps to reproduce: 1. Checkout branch from this PR [1] 2. Change getLocalPart() on this line to toString() [2] 3. Run test [3] 4. Run test [4] Test from point 3. fails on validation error, because the validation rule fired - the typeRef from the provided Definitions contains namespace. However test from point 4. pass, because unmarshalling from the validate method that takes Reader as an input works differently and doesn't fill namespace in the typeref. This is inconsistent, because a user could expect that the validate methods behave the same when the same file is used (either for getting Definitions or providing it directly to the validate method). [1] https://github.com/kiegroup/drools/pull/1810 [2] https://github.com/baldimir/drools/blob/5a9cb6f09a52cdc46b7cafb52cf615f88... [3] https://github.com/baldimir/drools/blob/7a2c6374351d57011ae67d4fc28900ea8... [4] https://github.com/baldimir/drools/blob/7a2c6374351d57011ae67d4fc28900ea8... > DMN Namespace unmarshalling differs from standard one when calling DMNValidator.validate method with File param > --------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2388 > URL: https://issues.jboss.org/browse/DROOLS-2388 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.6.0.Final > Reporter: Tibor Zimányi > Assignee: Fedor Gavrilov > Priority: Minor > > When using DMNValidator.validate method that takes a DMN file as a parameter, the validation results are sometimes different from results of validate method that takes Definitions as an input parameter. The main difference looks to be namespace parsing. > Reproducer can be found here: https://github.com/kiegroup/drools/pull/1814 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2388) DMN Namespace unmarshalling differs from standard one when calling DMNValidator.validate method with File param

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2388?page=com.atlassian.jira.plugi... ] Tibor Zimányi commented on DROOLS-2388: --------------------------------------- Steps to reproduce: 1. Checkout branch from this PR [1] 2. Change getLocalPart() on this line to toString() [2] 3. Run test [3] 4. Run test [4] Test from point 3. fails on validation error, because the validation rule fired - the typeRef from the provided Definitions contains namespace. However test from point 4. pass, because unmarshalling from the validate method that takes Reader as an input works differently and doesn't fill namespace in the typeref. This is inconsistent, because a user could expect that the validate methods behave the same when the same file is used (either for getting Definitions or providing it directly to the validate method). [1] https://github.com/kiegroup/drools/pull/1810 [2] https://github.com/baldimir/drools/blob/5a9cb6f09a52cdc46b7cafb52cf615f88... [3] https://github.com/baldimir/drools/blob/7a2c6374351d57011ae67d4fc28900ea8... [4] https://github.com/baldimir/drools/blob/7a2c6374351d57011ae67d4fc28900ea8... > DMN Namespace unmarshalling differs from standard one when calling DMNValidator.validate method with File param > --------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2388 > URL: https://issues.jboss.org/browse/DROOLS-2388 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.6.0.Final > Reporter: Tibor Zimányi > Assignee: Fedor Gavrilov > Priority: Minor > > When using DMNValidator.validate method that takes a DMN file as a parameter, the validation results are sometimes different from results of validate method that takes Definitions as an input parameter. The main difference looks to be namespace parsing. > Reproducer can be found here: https://github.com/kiegroup/drools/pull/1814 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-2405) Run AddRemoveRulesTest as a standard test, not as a turtle test

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-2405: ------------------------------------- Summary: Run AddRemoveRulesTest as a standard test, not as a turtle test Key: DROOLS-2405 URL: https://issues.jboss.org/browse/DROOLS-2405 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.6.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi We currently run AddRemoveRulesTest as a turtle test, so it is not run as a standard test during each build (e.g. PR build). It should be a standard test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-9501) Container is not cleaning up container-managed JMSContext

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-9501?page=com.atlassian.jira.plugin.... ] Kabir Khan resolved WFLY-9501. ------------------------------ Fix Version/s: 13.0.0.Beta1 Resolution: Done > Container is not cleaning up container-managed JMSContext > --------------------------------------------------------- > > Key: WFLY-9501 > URL: https://issues.jboss.org/browse/WFLY-9501 > Project: WildFly > Issue Type: Bug > Components: EE, EJB, JMS > Affects Versions: 12.0.0.Beta1 > Environment: JBoss-EAP-7.0.0 > JDK 1.8 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > Fix For: 13.0.0.Beta1 > > > The container is not cleaning up container managed JMSContext, causing a connection leak. > The JMS 2.0 API doc[1] states the following : > <quote> > Applications running in the Java EE web and EJB containers may alternatively inject a JMSContext into their application using the @Inject annotation. A JMSContext that is created in this way is described as being container-managed. A container-managed JMSContext will be closed automatically by the container. > </quote> > However the JCA's CacheConnectionManager (CCM) complains a connection leak if the application didn't explicitly close the JMSContext, which is not required for container managed JMSContext. > [1] http://docs.oracle.com/javaee/7/api/javax/jms/JMSContext.html -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10046) Cannot create cluster with JGroups Gossip router

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-10046?page=com.atlassian.jira.plugin... ] Miroslav Novak commented on WFLY-10046: --------------------------------------- FRAG2... config was taken from EAP 7.1. I've changed udp to gosship and socket binding. Thanks! > Cannot create cluster with JGroups Gossip router > ------------------------------------------------ > > Key: WFLY-10046 > URL: https://issues.jboss.org/browse/WFLY-10046 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Final > Reporter: Miroslav Novak > Assignee: Paul Ferraro > Attachments: standalone-full-ha-gosship1.xml, standalone-full-ha-gosship2.xml > > > I've used config from EAP 7.1.0/WF11 where gossip router was configured in udp stack like: > {code} > <stack name="udp"> > <transport type="UDP" shared="false" socket-binding="jgroups-udp"/> > <protocol type="PING"/> > <protocol type="MERGE3"/> > <protocol type="FD_SOCK"/> > <protocol type="FD_ALL"/> > <protocol type="VERIFY_SUSPECT"/> > <protocol type="pbcast.NAKACK2"/> > <protocol type="UNICAST3"/> > <protocol type="pbcast.STABLE"/> > <protocol type="pbcast.GMS"/> > <protocol type="UFC"/> > <protocol type="MFC"/> > <protocol type="FRAG2"/> > <protocol type="TUNNEL"> > <property name="gossip_router_hosts"> > 0.0.0.0[12001] > </property> > </protocol> > </stack> > {code} > Gossip router was started on localhost: > {{java -cp $JBOSS_HOME//bin/client/jboss-client.jar org.jgroups.stack.GossipRouter -port 12001 -bindaddress 0.0.0.0}} > but cluster does not form up. The same configuration works in EAP 7.1. > Attaching xml config files for both of the servers. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 March 2018