February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (SECURITY-530) Implement a TOTP Login Module

by Anil Saldhana (JIRA)

Implement a TOTP Login Module ----------------------------- Key: SECURITY-530 URL: https://jira.jboss.org/browse/SECURITY-530 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: PicketBox_v3_0_CR1 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: PicketBox_v3_0_CR2 It should be possible for an user to enter a TOTP value from any handheld device into a text box in the login form of a web application. This login module can then validate the totp entered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-659) unable to download archetype-catalog.xml from releases repo

by Ian Springer (JIRA)

unable to download archetype-catalog.xml from releases repo ----------------------------------------------------------- Key: JBBUILD-659 URL: https://jira.jboss.org/browse/JBBUILD-659 Project: JBoss Build System Issue Type: Bug Components: Artifact Repositories Affects Versions: Maven Repository Nexus Rollout Reporter: Ian Springer $ wget https://repository.jboss.org/nexus/content/repositories/releases/archetyp... --2010-11-02 15:28:40-- https://repository.jboss.org/nexus/content/repositories/releases/archetyp... Resolving repository.jboss.org... 10.5.105.13 Connecting to repository.jboss.org|10.5.105.13|:443... connected. HTTP request sent, awaiting response... 500 Internal Server Error 2010-11-02 15:28:42 ERROR 500: Internal Server Error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-4078) DeploymentManager.getAvailableModules() returns null

by Libor Kotouc (JIRA)

DeploymentManager.getAvailableModules() returns null ---------------------------------------------------- Key: JBAS-4078 URL: http://jira.jboss.com/jira/browse/JBAS-4078 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-5.0.0.Beta2 Environment: JBoss 5.0.0.beta2 trunk build 20070206, JDK 1.5.0_08 Reporter: Libor Kotouc Assigned To: Dimitris Andreadis Priority: Critical This issue blocks an integration of JBoss AS 5 into NetBeans IDE. Steps to reproduce the behavior: 1. create a simple web application and copy the .war file into the deploy directory (I used the 'default' server) 2. start JBoss server (./run.sh) 3. run the following code from a J2SE application (I added JBoss jars to the classpath): public class Main { public static void main(String[] args) { try { javax.enterprise.deploy.spi.factories.DeploymentFactory df = new org.jboss.deployment.spi.factories.DeploymentFactoryImpl(); javax.enterprise.deploy.spi.DeploymentManager dm; dm = df.getDeploymentManager("http://org.jboss.deployment/jsr88", null, null); javax.enterprise.deploy.spi.Target[] targets = dm.getTargets(); javax.enterprise.deploy.spi.TargetModuleID[] modules; modules = dm.getAvailableModules(javax.enterprise.deploy.shared.ModuleType.WAR, targets); System.out.println(targets.length + " " + targets[0]); System.out.println(modules); } catch (javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException ex) { } catch (javax.enterprise.deploy.spi.exceptions.TargetException ex) { } } } The output of System.out.println statements is: 1 org.jboss.deployment.spi.JMXTarget@161d36b null I expect the module representing the web application, but null is returned. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-1279) ENCRYPT: algorithm provider only half implemented

by Bela Ban (JIRA)

ENCRYPT: algorithm provider only half implemented ------------------------------------------------- Key: JGRP-1279 URL: https://issues.jboss.org/browse/JGRP-1279 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.6.19, 2.12 [Dennis Reed] ENCRYPT allows the asym_provider to be specified. But it only uses it for the KeyGenerator lookup, not the Cipher lookup. And the sym_provider is hard-coded to null. Is there a reason the sym_provider isn't configurable, and that the providers aren't used for the Cipher lookups? This is causing issues for a customer, because they have an application that inserts a security provider at the beginning of the list. When JGroups first starts, it uses the default provider (BouncyCastle), but if there's a shun/reconnect after the application has inserted its provider, JGroups switches to the application's provider. And since some members are now using a different provider, they can't communicate. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1205) Retransmitter reset does not prevent new task addition after chanel close

by Vladimir Blagojevic (JIRA)

Retransmitter reset does not prevent new task addition after chanel close ------------------------------------------------------------------------- Key: JGRP-1205 URL: https://jira.jboss.org/browse/JGRP-1205 Project: JGroups Issue Type: Bug Affects Versions: 2.9, 2.8, 2.7, 2.6.15 Reporter: Vladimir Blagojevic Assignee: Bela Ban Fix For: 2.10 Sometimes, messages are being added to the Retransmitter *after* a channel has been . This can happen if OOB messages are being passed around at the time a channel leaving a group. The problem occurs in that messages are added after Retransmitter.reset(). Normally, the timer is also stopped when the channel is disconnected, but since the Timer is shared amongst all channels, any messages added to Retransmitter after reset() just continue to be requested because the timer that those tasks were scheduled on did not die. This can be solved by either specifically stopping the Retransmitter or giving each ProtocolAdapter their own Timer which is then shutdown on channel disconnect. Michael -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

4
7
0 / 0

[JBoss JIRA] Updated: (JBAS-8849) Interceptors, decorators and alternatives should be per archive

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/JBAS-8849?page=com.atlassian.jira.plugin.... ] Ales Justin updated JBAS-8849: ------------------------------ Affects Version/s: 6.0.0.Final > Interceptors, decorators and alternatives should be per archive > --------------------------------------------------------------- > > Key: JBAS-8849 > URL: https://issues.jboss.org/browse/JBAS-8849 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.Final > Reporter: Ales Justin > > Per 12.1 spec: > - Which alternatives, interceptors and decorators are enabled for *each* bean archive -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBAS-8849) Interceptors, decorators and alternatives should be per archive

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/JBAS-8849?page=com.atlassian.jira.plugin.... ] Ales Justin moved WELD-847 to JBAS-8849: ---------------------------------------- Project: JBoss Application Server (was: Weld) Key: JBAS-8849 (was: WELD-847) Issue Type: Bug (was: Task) Component/s: Weld/CDI (was: Infrastructure) (was: Interceptors and Decorators) Security: Public > Interceptors, decorators and alternatives should be per archive > --------------------------------------------------------------- > > Key: JBAS-8849 > URL: https://issues.jboss.org/browse/JBAS-8849 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Reporter: Ales Justin > > Per 12.1 spec: > - Which alternatives, interceptors and decorators are enabled for *each* bean archive -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JBAS-8848) Allow the setting of the community string stored in snmp traps in the SNMP adapter

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/JBAS-8848?page=com.atlassian.jira.plugin.... ] Masafumi Miura deleted JBAS-8848: --------------------------------- > Allow the setting of the community string stored in snmp traps in the SNMP adapter > ---------------------------------------------------------------------------------- > > Key: JBAS-8848 > URL: https://issues.jboss.org/browse/JBAS-8848 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Masafumi Miura > > The SNMP adapter includes the hardcoded "public" community with each generated trap. > The community string in traps is optional and in most cases of no use to a monitoring manager. A manager can always restrict the trap it receives based on the originating host/port combination. Those are set in snmp-adaptor.sar/managers.xml. > However, it would be nice to be able to set the community string in traps (or choose to not set it at all) per receiving manager. > This means that the configuration file for monitoring manager would have to be extended, e.g.: > <manager> > <address>localhost</address> > <port>1162</port> > <local-address></local-address> > <local-port></local-port> > <community>custom community string</community> <=== HERE > <version>1</version> > </manager> > For backwards compatibility, absense of the <community> element could be interpreted as "public", while an empty element could mean "no community string" -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-8848) Allow the setting of the community string stored in snmp traps in the SNMP adapter

by Masafumi Miura (JIRA)

Allow the setting of the community string stored in snmp traps in the SNMP adapter ---------------------------------------------------------------------------------- Key: JBAS-8848 URL: https://issues.jboss.org/browse/JBAS-8848 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: SNMP adapter Affects Versions: JBossAS-4.2.3.GA Reporter: Masafumi Miura The SNMP adapter includes the hardcoded "public" community with each generated trap. The community string in traps is optional and in most cases of no use to a monitoring manager. A manager can always restrict the trap it receives based on the originating host/port combination. Those are set in snmp-adaptor.sar/managers.xml. However, it would be nice to be able to set the community string in traps (or choose to not set it at all) per receiving manager. This means that the configuration file for monitoring manager would have to be extended, e.g.: <manager> <address>localhost</address> <port>1162</port> <local-address></local-address> <local-port></local-port> <community>custom community string</community> <=== HERE <version>1</version> </manager> For backwards compatibility, absense of the <community> element could be interpreted as "public", while an empty element could mean "no community string" -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-291) CoreGroupCommunicationService not compatible with RELAY protocol

by Paul Ferraro (JIRA)

CoreGroupCommunicationService not compatible with RELAY protocol ---------------------------------------------------------------- Key: JBCLUSTER-291 URL: https://issues.jboss.org/browse/JBCLUSTER-291 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Components: HA-Server-Core Affects Versions: HA-Server-Core 1.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: HA-Server-Core 1.0.1.Final Using the relay protocol in JGroups 2.12, CoreGroupCommunicationService.ClusterNodeFactoryImpl chokes (throws an IllegalStateException) when trying to determine the physical address (org.jgroups.stack.IpAddress) of a proxied member. Currently, the physical address is determined by sending a Event.GET_PHYSICAL_ADDRESS event down the stack. When the stack contains RELAY, a null is returned. The value returned by this downcall is used by ClusterNodeFactoryImpl to generate a meaningful name using the IP address and port as reported by JGroups. We need to either: * Have RELAY respond to GET_PHYSICAL_ADDRESS events with a meaningful address * Use some other mechanism to supply ClusterNode with a unique name -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 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 February 2011