[JBoss JIRA] Created: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
4:15 a.m.
Securing web-app REALLY cause incorrect character encoding in GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR2, JBossAS-5.0.0.CR1
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:28 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Anil Saldhana commented on JBAS-6213:
-------------------------------------
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190430
Look at my suggestion on configuring form authenticator in context.xml in WEB-INF
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:32 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Anil Saldhana commented on JBAS-6213:
-------------------------------------
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77217&am...
Look for the contents of the context.xml that go into WEB-INF
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:37 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Remy Maucherat commented on JBAS-6213:
--------------------------------------
The call to parameters there is not a good idea, and seems to be done for logging purposes
if audit is enabled.
JBossWebRealm seems to have enableAudit to true by default, so maybe setting
enableAudit="false" on the Realm element in server.xml could do something
useful. I would recommend NOT enabling audit by default, logging this much stuff, which
could be security sensitive, is a problem IMO.
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:41 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Anil Saldhana commented on JBAS-6213:
-------------------------------------
The simplest to do is comment out the category in conf/jboss-log4j.xml
We do the audit but mask passwords.
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:43 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Anil Saldhana commented on JBAS-6213:
-------------------------------------
Disable the following category in conf/jboss-log4j.xml
==================
<!-- Category specifically for Security Audit Provider -->
<category name="org.jboss.security.audit.providers.LogAuditProvider"
additivity="false">
<priority value="TRACE"/>
<appender-ref ref="AUDIT"/>
</category>
========================
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:55 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Igor A Tarasov commented on JBAS-6213:
--------------------------------------
These are absolutely different problems, please do not mix them.
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:48 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Remy Maucherat commented on JBAS-6213:
--------------------------------------
Anil, I really cannot see a way to justify enableAudit="true" as the default on
the Realm, and the audit thing is logging way too much stuff: cookies, parameters, HTTP
headers, attributes. This is a security issue, and is an abusively high level of logging.
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:56 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Anil Saldhana commented on JBAS-6213:
-------------------------------------
It is generating an AuditEvent to be passed to the audit framework. It is the
configuration from the user that decides whether the audit event is logged or not. It is
no different from the requestdispatcher or access log valves. We need this as part of the
security audit.
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:14 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Igor A Tarasov commented on JBAS-6213:
--------------------------------------
Yes, before creating my bug report, I have disabled loggin as it has been described in
other bug report with a similar problem.
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:24 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
jimyip commented on JBAS-6213:
------------------------------
Hi Anil,
Actually, I was using valve to find out what was going on.
However, valve is not a good way to solve this problem. For non-English users, they will
face this problem and lose many hairs until they find it out from the web that they have
to do an <b>extra configuration</b> to set the encoding in the valve.
Most developers know to set character encoding in FILTER but Jboss structure forces them
to use valve to do the same thing. I don't know other JEE app servers how to solve
this problem, but to users(developers), valve is absolutely not a good method. Developers
will not expect that Jboss has touched the request parameters BEFORE their client codes
touches them.
Besides setting "enableAuditFlag" as false by default in audit config
(JBAS-6217), I suggest to add parameters in audit config :
1) a 'auditCharacterEncoding' parameter to 'help' users to set encoding so
they do not need filter or valve; OR/AND
2) a 'enableAuditRequestParameter' ('false' by default ) parameter to
let user choose if he wants to log the request parameters info.
Currently, is there any way to add any interceptors / filters (but not valve) before
processing Jboss security check?
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:56 a.m.
New subject: [JBoss JIRA] Commented: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Igor A Tarasov commented on JBAS-6213:
--------------------------------------
This issue is fixed in 5.0.0.GA and can be closed already.
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:14 p.m.
New subject: [JBoss JIRA] Updated: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Anil Saldhana updated JBAS-6213:
--------------------------------
Fix Version/s: JBossAS-5.0.0.GA
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Fix For: JBossAS-5.0.0.GA
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:14 p.m.
New subject: [JBoss JIRA] Closed: (JBAS-6213) Securing web-app REALLY cause incorrect character encoding in GET/POST data
[
https://jira.jboss.org/jira/browse/JBAS-6213?page=com.atlassian.jira.plug...
]
Anil Saldhana closed JBAS-6213.
-------------------------------
Resolution: Done
Securing web-app REALLY cause incorrect character encoding in
GET/POST data
---------------------------------------------------------------------------
Key: JBAS-6213
URL: https://jira.jboss.org/jira/browse/JBAS-6213
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Security, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.CR1, JBossAS-5.0.0.CR2
Environment: Fedora 8
JDK 1.5+
IE 7/Firefox 3
Reporter: jimyip
Assignee: Anil Saldhana
Priority: Critical
Fix For: JBossAS-5.0.0.GA
Similar problem found as stated by JBAS-5976.
I also found the problem as stated by Igor. After several days work, it is the problem of
JBoss SX layer which 'touch' ServletRequest.getParameterNames() (From
"AbstractJavaEEHelper" and "WebResource.deriveUsefulInfo()") and
caused the encoding set according to the OS before any character encoding filter can be
applied.
I use a wrapper Request to show the calling path. Below are the stacktrace:
at my.tomcat.hack.RequestHack.getParameterNames(RequestHack.java:420)
at
org.jboss.security.authorization.resources.WebResource.deriveUsefulInfo(WebResource.java:152)
at
org.jboss.security.authorization.resources.WebResource.toString(WebResource.java:123)
at
org.jboss.security.javaee.AbstractJavaEEHelper.authorizationAudit(AbstractJavaEEHelper.java:100)
at
org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:183)
at
org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:636)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:91)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:92)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at my.tomcat.valve.RequestInspectorValve.invoke(RequestInspectorValve.java:90)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5872
days inactive
5897
days old
13 comments
4 participants
participants (4)
-
Anil Saldhana (JIRA) -
Igor A Tarasov (JIRA)
-
jimyip (JIRA)
-
Remy Maucherat (JIRA)