September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2522) [DMN Designer] Palette aesthetics

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2522?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2522: ----------------------------------- Sprint: 2018 Week 39-41 > [DMN Designer] Palette aesthetics > --------------------------------- > > Key: DROOLS-2522 > URL: https://issues.jboss.org/browse/DROOLS-2522 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.8.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Labels: drools-tools > Attachments: palette.png > > > The palette css styling has changed. There appeared margins between items in palette, what is probably not problem, however even when user click to this margin (to space between two item in palette) still some palette item is selected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1672) MechanismDatabase should not use AEAD to describe digest (PRF)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1672?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1672: ---------------------------------- Fix Version/s: 1.7.0.CR2 > MechanismDatabase should not use AEAD to describe digest (PRF) > -------------------------------------------------------------- > > Key: ELY-1672 > URL: https://issues.jboss.org/browse/ELY-1672 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.7.0.CR2 > > > AEAD is not a digest (PRF) function, it's a description of a message authentication strategy. We should only use the actual digest names in the mechanism database. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1674) MechanismDatabase ECDHE_PSK ciphers use PSK authentication, not ECDHE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1674?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1674: ---------------------------------- Fix Version/s: 1.7.0.CR2 > MechanismDatabase ECDHE_PSK ciphers use PSK authentication, not ECDHE > --------------------------------------------------------------------- > > Key: ELY-1674 > URL: https://issues.jboss.org/browse/ELY-1674 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.7.0.CR2 > > > AFAICT the ECHDE_PSK suites use PSK authentication, not ECDHE key authentication. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1673) Draft ciphers in mechanism database

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1673?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1673: ---------------------------------- Fix Version/s: 1.7.0.CR2 > Draft ciphers in mechanism database > ----------------------------------- > > Key: ELY-1673 > URL: https://issues.jboss.org/browse/ELY-1673 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.7.0.CR2 > > > We should exclude the list of draft ciphers from the mechanism database. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1675) Merge roles from entry and entry attributes

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1675?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1675: ---------------------------------- Fix Version/s: 1.7.0.CR2 > Merge roles from entry and entry attributes > ------------------------------------------- > > Key: ELY-1675 > URL: https://issues.jboss.org/browse/ELY-1675 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Critical > Fix For: 1.7.0.CR2 > > > Double check Elytron ldap realm is capable doing this: > Having ldap entries like this > {code} > dn: cn=jduke,ou=Roles,ou=example2,${dnSuffix} > objectClass: top > objectClass: organizationalRole > description: cn=Echo,ou=Roles,ou=example2,${dnSuffix} > description: cn=TheDuke,ou=Roles,ou=example2,${dnSuffix} > cn: jduke > {code} > User will have roles jduke, Echo and TheDuke. > This was possible with Picketbox with this configuration > {code} > EapSetupTask roleAttributesConfiguration = > new LdapExtSecurityDomainBuilder(SECURITY_DOMAIN_NAME_PREFIX + DEP2) > .prepareDefaultForLdapServer(ldapServer) > .baseCtxDN("ou=People,ou=example2," + ldapServer.getDNSuffix()) > .rolesCtxDN("ou=Roles,ou=example2," + ldapServer.getDNSuffix()) > .referral("ignore") > .roleFilter("(|(objectClass=referral)(cn={0}))") > .roleAttributeID("description") > .roleAttributeIsDN("true") > .roleNameAttributeID("cn") > .roleRecursion("0") > .configure(); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1676) Add missing ARIA encryption to CipherSuiteSelector

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1676?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1676: ---------------------------------- Fix Version/s: 1.7.0.CR2 > Add missing ARIA encryption to CipherSuiteSelector > -------------------------------------------------- > > Key: ELY-1676 > URL: https://issues.jboss.org/browse/ELY-1676 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Martin Mazanek > Assignee: Martin Mazanek > Fix For: 1.7.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1677) Elytron Bearer Token Authentication - Return a 401 on Invalid Token

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1677?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1677: ------------------------------------- Assignee: Darran Lofthouse > Elytron Bearer Token Authentication - Return a 401 on Invalid Token > ------------------------------------------------------------------- > > Key: ELY-1677 > URL: https://issues.jboss.org/browse/ELY-1677 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Mechanisms > Affects Versions: 1.7.0.CR1 > Reporter: Edward Stathopoulos > Assignee: Darran Lofthouse > Fix For: 1.7.0.CR2 > > > *Issue* > Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...]. > It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question? > This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token. > {quote} > And in response to a protected resource request with an > authentication attempt using an expired access token: > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Bearer realm="example", > error="invalid_token", > error_description="The access token expired" > {quote} > *Potential Solution* > Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source. > {code} > if (verifyCallback.isVerified()) { > AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null); > handleCallback(authorizeCallback); > if (authorizeCallback.isAuthorized()) { > httpBearer.debugf("Token authentication successful."); > handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true)); > handleCallback(AuthenticationCompleteCallback.SUCCEEDED); > request.authenticationComplete(); > return; > } > else{ > httpBearer.debugf("Token authorization failed message."); > request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN)); > return; > } > } > httpBearer.debugf("Token authentication failed."); > request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED)); > return; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1677) Elytron Bearer Token Authentication - Return a 401 on Invalid Token

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1677?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1677: ---------------------------------- Fix Version/s: 1.7.0.CR2 > Elytron Bearer Token Authentication - Return a 401 on Invalid Token > ------------------------------------------------------------------- > > Key: ELY-1677 > URL: https://issues.jboss.org/browse/ELY-1677 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Mechanisms > Affects Versions: 1.7.0.CR1 > Reporter: Edward Stathopoulos > Fix For: 1.7.0.CR2 > > > *Issue* > Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...]. > It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question? > This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token. > {quote} > And in response to a protected resource request with an > authentication attempt using an expired access token: > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Bearer realm="example", > error="invalid_token", > error_description="The access token expired" > {quote} > *Potential Solution* > Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source. > {code} > if (verifyCallback.isVerified()) { > AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null); > handleCallback(authorizeCallback); > if (authorizeCallback.isAuthorized()) { > httpBearer.debugf("Token authentication successful."); > handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true)); > handleCallback(AuthenticationCompleteCallback.SUCCEEDED); > request.authenticationComplete(); > return; > } > else{ > httpBearer.debugf("Token authorization failed message."); > request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN)); > return; > } > } > httpBearer.debugf("Token authentication failed."); > request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED)); > return; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-203) LogManager stops any logging output after changing "encoding" attribute to file-handler

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-203?page=com.atlassian.jira.plugin... ] David Lloyd reassigned LOGMGR-203: ---------------------------------- Assignee: David Lloyd (was: James Perkins) > LogManager stops any logging output after changing "encoding" attribute to file-handler > --------------------------------------------------------------------------------------- > > Key: LOGMGR-203 > URL: https://issues.jboss.org/browse/LOGMGR-203 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Reporter: Masafumi Miura > Assignee: David Lloyd > > When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler. > Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change. > Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler. > {code} > LogManager error of type FLUSH_FAILURE: Error on flush > java.io.IOException: Stream Closed > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:326) > at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) > at java.io.BufferedWriter.flush(BufferedWriter.java:254) > at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170) > at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139) > at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105) > at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) > at org.jboss.logmanager.Logger.logRaw(Logger.java:850) > at org.jboss.logmanager.Logger.log(Logger.java:802) > at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53) > at org.jboss.logging.Logger.logf(Logger.java:2398) > at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42) > at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150) > at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364) > at java.lang.Thread.run(Thread.java:748) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11081) LogManager stops any logging output after changing "encoding" attribute to file-handler

by David Lloyd (JIRA)

David Lloyd created WFLY-11081: ---------------------------------- Summary: LogManager stops any logging output after changing "encoding" attribute to file-handler Key: WFLY-11081 URL: https://issues.jboss.org/browse/WFLY-11081 Project: WildFly Issue Type: Bug Components: Logging Affects Versions: 14.0.0.Final Reporter: Masafumi Miura Assignee: James Perkins When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler. Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change. Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler. {code} LogManager error of type FLUSH_FAILURE: Error on flush java.io.IOException: Stream Closed at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:326) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110) at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) at java.io.BufferedWriter.flush(BufferedWriter.java:254) at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170) at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139) at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105) at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67) at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341) at org.jboss.logmanager.Logger.logRaw(Logger.java:850) at org.jboss.logmanager.Logger.log(Logger.java:802) at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53) at org.jboss.logging.Logger.logf(Logger.java:2398) at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42) at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150) at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364) at java.lang.Thread.run(Thread.java:748) {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 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 2018