November 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.

by Liz Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ] Liz Clayton updated DROOLS-3393: -------------------------------- Attachment: Screen Shot 2018-11-30 at 12.05.50 PM.png > Please review scenario error cell text for legibility/accessibility. > --------------------------------------------------------------------- > > Key: DROOLS-3393 > URL: https://issues.jboss.org/browse/DROOLS-3393 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Liz Clayton > Assignee: Klara Kufova > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screen Shot 2018-11-30 at 11.59.32 AM.png, Screen Shot 2018-11-30 at 12.05.50 PM.png, Screenshot from 2018-11-30 17-11-43.png > > > [~kkufova] [~bdellasc] > I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded. > I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes. > I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible. > Just wanted to ask about this, please let me know what you think. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.

by Liz Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3393?page=com.atlassian.jira.plugi... ] Liz Clayton updated DROOLS-3393: -------------------------------- Attachment: Screen Shot 2018-11-30 at 11.59.32 AM.png > Please review scenario error cell text for legibility/accessibility. > --------------------------------------------------------------------- > > Key: DROOLS-3393 > URL: https://issues.jboss.org/browse/DROOLS-3393 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Liz Clayton > Assignee: Klara Kufova > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screen Shot 2018-11-30 at 11.59.32 AM.png, Screen Shot 2018-11-30 at 12.05.50 PM.png, Screenshot from 2018-11-30 17-11-43.png > > > [~kkufova] [~bdellasc] > I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded. > I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes. > I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible. > Just wanted to ask about this, please let me know what you think. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3393) Please review scenario error cell text for legibility/accessibility.

by Liz Clayton (Jira)

Liz Clayton created DROOLS-3393: ----------------------------------- Summary: Please review scenario error cell text for legibility/accessibility. Key: DROOLS-3393 URL: https://issues.jboss.org/browse/DROOLS-3393 Project: Drools Issue Type: Task Components: Scenario Simulation and Testing Reporter: Liz Clayton Assignee: Klara Kufova [~kkufova] [~bdellasc] I noticed that the error text is a little "fuzzy" looking, the edges aren't very sharp and I was concerned that it might not be legible. I asked Danielle about the specs for it and it's the same size just bolded. I did an online accessibility text using the following tool, with our current hex values: https://webaim.org/resources/contrastchecker/. It failed for level 3 compliance, but I'm not sure we need to shoot for that or not? I tried the darker PatternFly red color "#8b0000" and it passed at all levels, even at smaller sizes. I'm wondering if we could use the darker red, in the non-bolded font? And if so, perhaps the text would be a little bit more legible. Just wanted to ask about this, please let me know what you think. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] Stefan Guilhen closed SECURITY-868. ----------------------------------- Resolution: Done > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Priority: Major > Fix For: PicketBox_4_9_0.Final > > Attachments: stacktraces.log > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-888) Revert changes made in SECURITY-868

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/SECURITY-888?page=com.atlassian.jira.plug... ] Stefan Guilhen closed SECURITY-888. ----------------------------------- Resolution: Done > Revert changes made in SECURITY-868 > ----------------------------------- > > Key: SECURITY-888 > URL: https://issues.jboss.org/browse/SECURITY-888 > Project: PicketBox > Issue Type: Task > Affects Versions: PicketBox_4_9_1.Final > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Priority: Major > Fix For: PicketBox_4_9_2.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-701) Wrong character table in Base64Utils

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/SECURITY-701?page=com.atlassian.jira.plug... ] Stefan Guilhen reassigned SECURITY-701: --------------------------------------- Assignee: (was: Stefan Guilhen) > Wrong character table in Base64Utils > ------------------------------------ > > Key: SECURITY-701 > URL: https://issues.jboss.org/browse/SECURITY-701 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Affects Versions: PicketBox_4_0_12.Final > Reporter: wiktorowski maximilien > Priority: Major > > In picketbox-4.0.7.Final.jar org.jboss.security.Base64Utils has a wrong character table > private static final char[] base64Table = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz./".toCharArray(); > It should be > private static final char[] base64Table = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+/".toCharArray(); -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1223) jboss-ejb-iiop_1_0.xsd does not match Java implementation

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/WFLY-1223?page=com.atlassian.jira.plugin.... ] Stefan Guilhen reassigned WFLY-1223: ------------------------------------ Assignee: (was: Stefan Guilhen) > jboss-ejb-iiop_1_0.xsd does not match Java implementation > --------------------------------------------------------- > > Key: WFLY-1223 > URL: https://issues.jboss.org/browse/WFLY-1223 > Project: WildFly > Issue Type: Task > Components: IIOP > Reporter: david.boeren > Priority: Minor > > There's a mismatch between the schema file in > docs/schema/jboss-ejb-iiop_1_0.xsd and the java classes that implement > the parsing of this schema. As is usual in such cases, it's probably > the documentation that is wrong. > In the xsd file the children are described as attributes: > <xs:complexType name="iorTransportConfigType"> > <xs:annotation> > <xs:documentation> > <![CDATA[ > The iorTransportConfigType specifies attributes that can > be used to configure the transport requirements of > an IIOP enabled EJB3 bean. > * integrity: indicates if the server (target) supports > integrity protected messages. The valid values are > NONE, SUPPORTED or REQUIRED. > * confidentiality: indicates if the server (target) > supports privacy protected messages. The values are > NONE, SUPPORTED or REQUIRED. > * detect-misordering: indicates if the server (target) > supports detection of message sequence errors. The > values are NONE, SUPPORTED or REQUIRED. > * detect-replay: indicates if the server (target) supports > detection of message replay attempts. The values > are NONE, SUPPORTED or REQUIRED. > * establish-trust-in-client: indicates if the target is > capable of authenticating a client. The values are > NONE, SUPPORTED or REQUIRED. > * establish-trust-in-target: indicates if the target is > capable of authenticating to a client. The values > are NONE or SUPPORTED. > ]]> > </xs:documentation> > </xs:annotation> > <xs:attribute name="integrity" type="xs:string" use="required" > default="NONE"/> > <xs:attribute name="confidentiality" type="xs:string" > use="required" default="NONE"/> > <xs:attribute name="detect-misordering" type="xs:string" > use="optional" default="NONE"/> > <xs:attribute name="detect-replay" type="xs:string" > use="optional" default="NONE"/> > <xs:attribute name="establish-trust-in-client" type="xs:string" > use="required" default="NONE"/> > <xs:attribute name="establish-trust-in-target" type="xs:string" > use="required" default="NONE"/> > </xs:complexType> > However, in the class > (org.jboss.metadata.ejb.parser.jboss.ejb3.IIOPMetaDataParser) it > requires no attributes and expects to see these same children as elements: > protected IORTransportConfigMetaData > processTransportConfig(XMLStreamReader reader, final PropertyReplacer > propertyReplacer) throws XMLStreamException { > // the transport-config element doesn't have attributes. > requireNoAttributes(reader); > EnumSet<Element> requiredElements = EnumSet.of(Element.INTEGRITY, > Element.CONFIDENTIALITY, > Element.ESTABLISH_TRUST_IN_CLIENT, Element.ESTABLISH_TRUST_IN_TARGET); > IORTransportConfigMetaData transportConfig = new > IORTransportConfigMetaData(); > // process the transport config elements. > while (reader.hasNext() && reader.nextTag() != END_ELEMENT) { > Element element = Element.forName(reader.getLocalName()); > // set the element text in the transport config metadata. > switch (element) { > case INTEGRITY: { > requireNoAttributes(reader); > transportConfig.setIntegrity(getElementText(reader, propertyReplacer)); > break; > } > case CONFIDENTIALITY: { > requireNoAttributes(reader); > transportConfig.setConfidentiality(getElementText(reader, > propertyReplacer)); > break; > } > case DETECT_MISORDERING: { > requireNoAttributes(reader); > transportConfig.setDetectMisordering(getElementText(reader, > propertyReplacer)); > break; > } > case DETECT_REPLAY: { > requireNoAttributes(reader); > transportConfig.setDetectReplay(getElementText(reader, propertyReplacer)); > break; > } > case ESTABLISH_TRUST_IN_CLIENT: { > requireNoAttributes(reader); > transportConfig.setEstablishTrustInClient(getElementText(reader, > propertyReplacer)); > break; > } > case ESTABLISH_TRUST_IN_TARGET: { > requireNoAttributes(reader); > transportConfig.setEstablishTrustInTarget(getElementText(reader, > propertyReplacer)); > break; > } > default: { > throw unexpectedElement(reader); > } > } > requiredElements.remove(element); > } > // throw an exception if a required element wasn't found. > if (!requiredElements.isEmpty()) { > throw missingRequiredElement(reader, requiredElements); > } > return transportConfig; > } -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-729) Provide an utility to perform Subject - SecurityIdentity conversions

by Stefan Guilhen (Jira)

[ https://issues.jboss.org/browse/ELY-729?page=com.atlassian.jira.plugin.sy... ] Stefan Guilhen reassigned ELY-729: ---------------------------------- Assignee: (was: Stefan Guilhen) > Provide an utility to perform Subject - SecurityIdentity conversions > -------------------------------------------------------------------- > > Key: ELY-729 > URL: https://issues.jboss.org/browse/ELY-729 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Affects Versions: 1.0.3.Final > Reporter: Stefan Guilhen > Priority: Major > > In WildFly there are subsystems that rely on Subject instances to fulfill their security requirements. We thus need an API to allow for the conversion of SecurityIdentity instances to Subject and vice versa. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3392) Workaround lack of xjc executable in JDK11

by Mario Fusco (Jira)

Mario Fusco created DROOLS-3392: ----------------------------------- Summary: Workaround lack of xjc executable in JDK11 Key: DROOLS-3392 URL: https://issues.jboss.org/browse/DROOLS-3392 Project: Drools Issue Type: Task Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3391) UI should select and highlight grid cells with menus.

by Liz Clayton (Jira)

Liz Clayton created DROOLS-3391: ----------------------------------- Summary: UI should select and highlight grid cells with menus. Key: DROOLS-3391 URL: https://issues.jboss.org/browse/DROOLS-3391 Project: Drools Issue Type: Task Components: Scenario Simulation and Testing Reporter: Liz Clayton Assignee: Daniele Zonca Grid cell with actions (contextual menus, pop-overs, etc.) should visually indicate a cell selection state (blue border) - both for usability and to align withAlign with DMN and GDT. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2018