April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-98) http -> https redirect port not respecting offset

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-98?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-98: ----------------------------- Assignee: Darran Lofthouse (was: Paul Ferraro) > http -> https redirect port not respecting offset > ------------------------------------------------- > > Key: WFLY-98 > URL: https://issues.jboss.org/browse/WFLY-98 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web) > Environment: JBoss AS 8 Alpha1 > Reporter: Frank Langelage > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > > I'm using JBoss AS 8 with new undertow integration: > <subsystem xmlns="urn:jboss:domain:undertow:1.0"> > <worker name="default" task-core-threads="12" io-threads="3"/> > <buffer-pool name="default" buffer-size="2048" buffers-per-slice="512"/> > <server name="default-server"> > <http-listener name="http" socket-binding="http"/> > <https-listener name="https" socket-binding="https" security-realm="UndertowRealm" /> > <ajp-listener name="ajp" socket-binding="ajp"/> > <host name="default-host" alias="localhost"> > <location name="/"> > <file path="${jboss.home.dir}/welcome-content" cache-buffer-size="1024" cache-buffers="1024"/> > </location> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > </servlet-container> > </subsystem> > Socket-binding is > <socket-binding name="ajp" port="8009"/> > <socket-binding name="http" port="8080"/> > <socket-binding name="https" port="8443"/> > and port-offset is 700. > So listeners are created on 8709, 8780 and 9143. > But when accessing a secured page, I get redirected from http:8780 to https:8443 instead of https:9143. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-96) ejb-security-interceptors quickstart has several issues

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-96?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated WFLY-96: ----------------------------- Assignee: Darran Lofthouse (was: Ondrej Zizka) > ejb-security-interceptors quickstart has several issues > ------------------------------------------------------- > > Key: WFLY-96 > URL: https://issues.jboss.org/browse/WFLY-96 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > > The ejb-security-interceptors quickstarts should be improved a little bit: > * root element of the {{jboss-ejb3.xml}} deployment descriptor should be {{<ejb-jar>}} (c.f. AS7-6452) > * DelegationLoginModule doesn't need the callbackHandler member variable, the parrent class holds it ({{AbstractServerLoginModule}}) > * possible {{EJBException}} from the {{invocationContext.proceed()}} call is not correctly propagated in the {{ServerSecurityInterceptor}} > The correct part of ServerSecurityInterceptor code should look like: > {code} > try { > if (desiredUser != null && connectionUser != null > && (desiredUser.getName().equals(connectionUser.getName()) == false)) { > // The final part of this check is to verify that the change does actually indicate a change in user. > try { > // We have been requested to switch user and have successfully identified the user from the connection > // so now we attempt the switch. > cachedSecurityContext = SecurityActions.securityContextSetPrincipalInfo(desiredUser, > new OuterUserCredential(connectionUser)); > // keep track that we switched the security context > contextSet = true; > SecurityActions.remotingContextClear(); > } catch (Exception e) { > logger.error("Failed to switch security context for user", e); > // Don't propagate the exception stacktrace back to the client for security reasons > throw new EJBAccessException("Unable to attempt switching of user."); > } > } > return invocationContext.proceed(); > } finally { > // switch back to original security context > if (contextSet) { > SecurityActions.securityContextSet(cachedSecurityContext); > } > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-326) Logout a remote client from server and clearing login module cache.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-326?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-326: ------------------------------ Assignee: Darran Lofthouse (was: Heiko Braun) > Logout a remote client from server and clearing login module cache. > ------------------------------------------------------------------- > > Key: WFLY-326 > URL: https://issues.jboss.org/browse/WFLY-326 > Project: WildFly > Issue Type: Feature Request > Components: Remoting, Security, Server > Environment: java 1.6 > win 7 64 bit > 4 gb ram > Reporter: Serkan Yıldırım > Assignee: Darran Lofthouse > Labels: Remoting_Management, jboss-as7, login-module, logout, remoting, security > Fix For: 8.0.0.Alpha1 > > > I have a custom login module. I authenticate and authorize a user (creating roles) by using this custom module. When i close the remote application, i want to logout the user from server so that clear login module cache, i.e deleting principals and roles from the cache. I couldn't find a solution for this problem in forum. If it exists, could you please explain it, thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-159) Local auth doesn't work on Windows when client uses link-local address without zone-id

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-159?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-159: ------------------------------ Assignee: Darran Lofthouse (was: Paul Ferraro) > Local auth doesn't work on Windows when client uses link-local address without zone-id > -------------------------------------------------------------------------------------- > > Key: WFLY-159 > URL: https://issues.jboss.org/browse/WFLY-159 > Project: WildFly > Issue Type: Bug > Components: CLI, Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > > This is most likely caused by an optimisation during initialisation that checks that the server being connected to is really local - if that server is not detected as being local from the address then the local authentication mechanism is omitted from the list of supported mechanisms. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1197) Port the legacy jmx-console to AS7

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1197?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-1197: ------------------------------- Assignee: Darran Lofthouse (was: Thomas Diesler) > Port the legacy jmx-console to AS7 > ---------------------------------- > > Key: WFLY-1197 > URL: https://issues.jboss.org/browse/WFLY-1197 > Project: WildFly > Issue Type: Feature Request > Components: JMX > Reporter: Dimitris Andreadis > Assignee: Darran Lofthouse > Labels: JMX, as7, jmx-console > Attachments: jmx-console.war, jmx-console.war > > > I've seen a few people asking for a port of the old jmx-console to AS7, for monitoring purposes, until equivalent functionality is available through the new GWT-based console. > I've ported the old console in this branch: > https://github.com/dandreadis/jboss-as/commits/jmx-console > It only includes a new top-level directory 'jmx-console'. The directory is not build by default, and when you build it manually it does not alter the server configuration in any way, you need to manually copy the resulting target/jboss-as-jmx-console-VERSION.war to the server deployment directory (and rename it to jmx-console.war) > If there is interest, it could be included in the AS7 distro in some top level 'legacy' directory so it is not deployed by default? > The resulting .war is attached on this JIRA, in case someone wants to use it. It work just as well on AS 7.0.2 and the latest AS 7.1.x development branch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-123) In non-interactive mode the add-user utility should replace duplicate users instead of reporting an error.

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-123?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-123: ------------------------------ Assignee: Darran Lofthouse (was: Brian Stansberry) > In non-interactive mode the add-user utility should replace duplicate users instead of reporting an error. > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-123 > URL: https://issues.jboss.org/browse/WFLY-123 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > > In non-interactive mode the ass-user utility should replace duplicate users instead of reporting an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1146) Export remoting-JMX address via JVM instrumentation buffer

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1146?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-1146: ------------------------------- Assignee: Darran Lofthouse (was: Stuart Douglas) > Export remoting-JMX address via JVM instrumentation buffer > ---------------------------------------------------------- > > Key: WFLY-1146 > URL: https://issues.jboss.org/browse/WFLY-1146 > Project: WildFly > Issue Type: Feature Request > Components: JMX > Reporter: James Livingston > Assignee: Darran Lofthouse > > Currently to connect to the AS with JConsole you need to manually enter the service:jmx:remoting-jmx:// address. When the local process connection is used, it retrieves the connection address via the Sun JDK management instrumentation buffer. > The exported address can be set via sun.management.ConnectorAddressLink.export(), and doing that would allow JConsole to connect without typing in the address (although still obviously require the jars to be on the classpath). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-430) Update the whoami operation to also show the authentication mechanism when called with verbose=true

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-430?page=com.atlassian.jira.plugin.s... ] Jason Greene updated WFLY-430: ------------------------------ Assignee: Darran Lofthouse (was: Thomas Diesler) > Update the whoami operation to also show the authentication mechanism when called with verbose=true > --------------------------------------------------------------------------------------------------- > > Key: WFLY-430 > URL: https://issues.jboss.org/browse/WFLY-430 > Project: WildFly > Issue Type: Task > Components: CLI, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.Alpha1 > > > I need to review if this is feasible but there are a number of reports coming in where end users believe their server is not secured because our local / silent mechanism is working so quietly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1113) JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1113?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-1113: ------------------------------- Assignee: Darran Lofthouse (was: Brian Stansberry) > JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml > --------------------------------------------------------------------------------------------- > > Key: WFLY-1113 > URL: https://issues.jboss.org/browse/WFLY-1113 > Project: WildFly > Issue Type: Feature Request > Components: Documentation > Environment: n/a > Reporter: Craig Ringer > Assignee: Darran Lofthouse > > There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc. > This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml. > Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1107) Documenting what is copyable between the domain and standalon xml files

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1107?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-1107: ----------------------------------- Assignee: (was: Brian Stansberry) > Documenting what is copyable between the domain and standalon xml files > ----------------------------------------------------------------------- > > Key: WFLY-1107 > URL: https://issues.jboss.org/browse/WFLY-1107 > Project: WildFly > Issue Type: Feature Request > Components: Documentation, Domain Management > Reporter: Jim Tyrrell > Labels: eap6-ux > > In the EAP6-UX meeting it was discussed that a smart user should be able to take the standalone.xml file and copy contents from it into a domain/host.xml file. From some point in the domain/host.xml files onwards the formats were said to be the same, is this true, if it is/is not the uniqueness needs to be documented, or strategies need to be explained. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2013