[
https://issues.apache.org/jira/browse/JSPWIKI-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045935#comment-15045935
]
Steven Walsh commented on JSPWIKI-924:
--------------------------------------
Hi Juan Pablo,
Thanks for looking into this. I agree with your suspicion that I have some sort
of misconfiguration, but so far I have had no luck in determining where that
misconfiguration lies. The #1 link you provided comes back as an invalid
address, so I could not read it. I'm not sure #2 is helpful due to my JAAS
environment. We host multiple applications on our Tomcat server and use a
central database to store user credentials. We have a custom authentication
class (via jar file to each application) that overrides standard JAAS requests
to do database queries for RolePrincipal and UserPrincipal authentication. That
process works fine for all the applications and it also works fine for the
JSPWiki login and page access control. Each of our JSPWiki user roles (admin,
approved, unapproved) are properly handled for the specified roles given to
each wiki page. Based on that, I believe the container authorization is an
unlikely suspect. Here is an extract from the jspwiki log for the
authentication of the admin user attempting to access the JSPWiki Main page:
****************************************************
2015-12-07 13:33:31.799 [http-bio-8080-exec-3] DEBUG AuthorizationManager 250 -
Checking for principal: [[org.apache.wiki.auth.authorize.Role: Authenticated],
[UnresolvedPrincipal: admin]]
2015-12-07 13:33:31.799 [http-bio-8080-exec-3] DEBUG AuthorizationManager 251 -
Permission:
("org.apache.wiki.auth.permissions.PagePermission","JSPWiki:Main","view")
2015-12-07 13:33:31.806 [http-bio-8080-exec-3] INFO AuthorizationManager 459 -
User WikiAdminUser has no access - redirecting
(permission=("org.apache.wiki.auth.permissions.PagePermission","JSPWiki:Main","view"))
2015-12-07 13:33:31.947 [http-bio-8080-exec-4] DEBUG CustomTomcatJaasModule 55
- initialize entered
2015-12-07 13:33:32.044 [http-bio-8080-exec-4] DEBUG CustomTomcatJaasModule 118
- user found with login = 'WikiAdminUser'
2015-12-07 13:33:32.058 [http-bio-8080-exec-4] DEBUG WikiServletFilter 107 -
Using ByteArrayResponseWrapper
2015-12-07 13:33:32.059 [http-bio-8080-exec-4] DEBUG SessionMonitor 117 -
Looking up WikiSession for session ID=E42032D57D20F20A796F97B86BADF3B3... found
it
2015-12-07 13:33:32.059 [http-bio-8080-exec-4] DEBUG WebContainerLoginModule
113 - Logged in container principal WikiAdminUser.
2015-12-07 13:33:32.063 [http-bio-8080-exec-4] DEBUG AbstractLoginModule 152 -
Committed Principal WikiAdminUser
2015-12-07 13:33:32.064 [http-bio-8080-exec-4] INFO SecurityLog 162 -
WikiSecurityEvent.LOGIN_AUTHENTICATED
[source=org.apache.wiki.auth.AuthenticationManager@8bc2356,
princpal=com.companytest.web.login.UserPrincipal WikiAdminUser,
target=org.apache.wiki.WikiSession@2c61cd3a]
2015-12-07 13:33:32.065 [http-bio-8080-exec-4] DEBUG SecurityLog 164 -
WikiSecurityEvent.LOGIN_AUTHENTICATED
[source=org.apache.wiki.auth.AuthenticationManager@8bc2356,
princpal=com.companytest.web.login.UserPrincipal WikiAdminUser,
target=org.apache.wiki.WikiSession@2c61cd3a]
2015-12-07 13:33:32.066 [http-bio-8080-exec-4] WARN WikiSession 688 - User
profile 'WikiAdminUser' not found. This is normal for container-auth users who
haven't set up a profile yet.
2015-12-07 13:33:32.072 [http-bio-8080-exec-4] DEBUG SecurityLog 164 -
WikiSecurityEvent.PRINCIPAL_ADD
[source=org.apache.wiki.auth.AuthenticationManager@8bc2356,
princpal=com.companytest.web.login.UserPrincipal WikiAdminUser,
target=org.apache.wiki.WikiSession@2c61cd3a]
2015-12-07 13:33:32.073 [http-bio-8080-exec-4] DEBUG SecurityLog 164 -
WikiSecurityEvent.PRINCIPAL_ADD
[source=org.apache.wiki.auth.AuthenticationManager@8bc2356,
princpal=org.apache.wiki.auth.authorize.Role admin,
target=org.apache.wiki.WikiSession@2c61cd3a]
2015-12-07 13:33:32.073 [http-bio-8080-exec-4] DEBUG AuthenticationManager 805
- Added container role admin.
2015-12-07 13:33:32.073 [http-bio-8080-exec-4] DEBUG SessionMonitor 117 -
Looking up WikiSession for session ID=E42032D57D20F20A796F97B86BADF3B3... found
it
2015-12-07 13:33:32.073 [http-bio-8080-exec-4] DEBUG SessionMonitor 117 -
Looking up WikiSession for session ID=E42032D57D20F20A796F97B86BADF3B3... found
it
2015-12-07 13:33:32.073 [http-bio-8080-exec-4] DEBUG WikiServletFilter 164 -
Executed security filters for user=WikiAdminUser, path=/JSPWiki/Login.jsp
****************************************************
Here is my jspwiki.policy file, minus most of the comment lines: Note that I
tried
explicitly to set the "upload" permission for the PagePermissions. The failure
occurred with and without the explicit setting.
=================================================
// Licensed to the Apache Software Foundation (ASF) under one
// ....
// The first policy block grants privileges that all users need, regardless of
// ....
grant principal org.apache.wiki.auth.authorize.Role "All" {
permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view";
};
// The second policy block is extremely loose, and unsuited for public-facing
wikis.
// ....
// Authenticated users can do most things: view, create, edit and
// comment on all pages; upload files to existing ones; create and edit
// wiki groups; and rename existing pages. Authenticated users can also
// edit groups they are members of.
// ....
grant principal org.apache.wiki.auth.authorize.Role "approved" {
permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view";
permission org.apache.wiki.auth.permissions.PagePermission "*:*", "edit";
permission org.apache.wiki.auth.permissions.PagePermission "*:*", "upload";
permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
permission org.apache.wiki.auth.permissions.GroupPermission
"*:<groupmember>", "edit";
permission org.apache.wiki.auth.permissions.WikiPermission "*",
"createPages";
permission org.apache.wiki.auth.permissions.WikiPermission "*",
"createProfile";
permission org.apache.wiki.auth.permissions.WikiPermission "*",
"editPreferences";
};
grant principal org.apache.wiki.auth.authorize.Role "unapproved" {
permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view";
permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
permission org.apache.wiki.auth.permissions.WikiPermission "*", "view";
};
// Administrators (principals or roles possessing AllPermission)
// ....
grant principal org.apache.wiki.auth.GroupPrincipal "admin" {
permission org.apache.wiki.auth.permissions.PagePermission "*:*", "upload";
permission org.apache.wiki.auth.permissions.AllPermission "*";
};
=================================================
The x.securityconfig.enable was helpful, and not. It is a nice tool to validate
the setup, but is basically telling me there is nothing wrong with my setup.
The only potential problem it flagged was my jspwiki.policy file does not have
a keystore, but then says "it also doesn't have any 'signedBy' blocks, so that
is probably OK".
The "Access Control Validation" section tells me for each of my
PagePermissions, 'All' has view rights; 'Anonymous', 'Asserted', and
'Authenticated' have no rights; 'unapproved' and 'admin' have view rights;
'approved' has view and edit rights;
For GroupPermissions, 'approved' and 'unapproved' have view permissions for the
admin group, which is correct but a configuration oversight on my part and I
need to remove them. None of the other users have any GroupPermissions.
For WikiPermissions, only 'approved' has permissions for createPages and
editPreferences. All other users have no permissions.
For AllPermissions, 'admin' is the only one with permission.
To me, all of that looks to be correct according to the jspwiki.policy entries.
The web container restrictions was interesting. It says my 'unapproved' has
view permissions, nothing else. That is how it should be.
It say my 'admin' has all permissions, which is how it should be. It says my
'approved' has all permissions except delete, which is how it should be. But
despite what that says, neither an 'approved' or 'admin' can upload
attachments. I double checked the wiki page I was using for testing and
verified it had no page-specific permission settings.
I ran a test and found my 'approved' user could add a comment, but an "Only
authorized users are allowed to rename pages." was shown in the info tab. The
'admin' user did have the rename and delete functions available. So the
'approved' user cannot rename a page, even though the Security Configuration
Verifier said they could.
I ran another test and changed all my references of 'approved' user to
'Authenticated' and got the same results I had with the 'approved' user, no
ability to rename a page or add attachments where the Security Configuration
Verifier said I could.
If it's useful here, is an extract from my jspwiki WEB-INF/web.xml file.
I noted that the <url-pattern>/attach</url-pattern> is in the Read-only Area
<web-resource-name>, but moving it into the Authenticated Area made
no difference.
--------------------------------------------------------------------------------------
<!-- REMOVE ME TO ENABLE CONTAINER-MANAGED AUTH
-->
<security-constraint>
<web-resource-collection>
<web-resource-name>Administrative Area</web-resource-name>
<url-pattern>/Delete.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
<!--
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
-->
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Authenticated area</web-resource-name>
<url-pattern>/Edit.jsp</url-pattern>
<url-pattern>/Comment.jsp</url-pattern>
<url-pattern>/Login.jsp</url-pattern>
<url-pattern>/NewGroup.jsp</url-pattern>
<url-pattern>/Rename.jsp</url-pattern>
<url-pattern>/Upload.jsp</url-pattern>
<url-pattern>/error/*</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>HEAD</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<web-resource-collection>
<web-resource-name>Read-only Area</web-resource-name>
<url-pattern>/attach</url-pattern>
<http-method>DELETE</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
<role-name>approved</role-name>
<role-name>unapproved</role-name>
</auth-constraint>
<!--
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
-->
</security-constraint>
--------------------------------------------------------------------------------------
Thanks for the pointer to youdebug. I'll have to take a look at it.
Please let me know if there is any other info that I can supply or
any other tests I can run.
Regards,
Steven
> Attachments fail using JAAS SSO container authentication
> --------------------------------------------------------
>
> Key: JSPWIKI-924
> URL: https://issues.apache.org/jira/browse/JSPWIKI-924
> Project: JSPWiki
> Issue Type: Bug
> Components: Core & storage
> Affects Versions: 2.10.1
> Environment: CentOS 6.5 OS, Tomcat 7.0.42, 32-byte single line plain
> text attachment test file.
> Reporter: Steven Walsh
> Priority: Minor
>
> I'm trying to implement JSPWiki in a JAAS authentication
> SSO environment. I have installed JSPWiki and made some
> minor adjustments to the jspwiki.policy to account for
> different user role names, and everything seems to be
> working OK, except for one thing. None of the users
> (including the administrator) can add attachments to
> any of the pages. If I run the wiki standalone, (outside
> JAAS), attachments work fine.
> I'm using JSPWiki 2.10.1 with Tomcat 7.0.42 on a CentOS
> 6.5 server. My attachment test file is a one-line 32 byte text file.
> I have three basic user roles, all require JAAS authorization
> to access the wiki. User roles are admin, approved (read
> and write for most pages), and unapproved (read only).
> I'm fairly confident that the authentication methods are
> working properly as all page permissions are working as
> expected for each user type.
> But when any admin or approved user tries to add an
> attachment to any page, they get redirected to an Error.jsp
> page showing a java.lang.Exception. To try and track down
> the error source, I rewrote the AttachmentServlet class
> and added a number of additional debug messages.
> Based on what I'm seeing, it appears to me that the error
> is caused by the upload.parseRequest ( req ) returning
> an empty List<FileItem> fileItems in the upload method.
> I added a debug line to verify the contents of the request
> and it is properly populated entering the upload method,
> but it is consumed @ req.getParameter( "progressid" ).
> I commented out the use of the progress bar and found
> the request consumption moves to the context creation
> @ m_engine.createContext( req, WikiContext.ATTACH );
> Once it is consumed there, there is nothing left for the
> upload.parseRequest (req ) to read.
> I realize that I consumed the request by reading it for the
> debug message, but I only used it once per test run to
> determine where it was consumed. In the following log
> extract, that was at time 2015-11-25 14:05:41.892,
> which was after the createContext and before the
> upload.parseRequest.
> I'm inexperienced with the doFilter mechanism, and I see
> that it is part of the exception dump, and I don't know if
> that is working or not, but since upload.parseRequest ( req )
> is returning an empty fileItems list, I suspect there is
> something going on there. But I'm in over my head here.
> This is the log extract, starting right after the container JAAS
> has authorized the user.
> =================
> 2015-11-25 14:05:41.797 [http-bio-8080-exec-1] DEBUG AttachmentServlet 168 -
> UploadServlet initialized. Using /home/testwiki/storage//attach-tmp for
> temporary storage.
> 2015-11-25 14:05:41.797 [http-bio-8080-exec-1] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.797 [http-bio-8080-exec-1] DEBUG WikiSession 851 - Custom
> com.apache.wiki.WikiSession.isIPV4Address has been entered
> 2015-11-25 14:05:41.798 [http-bio-8080-exec-1] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.798 [http-bio-8080-exec-1] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.798 [http-bio-8080-exec-1] DEBUG WikiServletFilter 164 -
> Executed security filters for user=AdminUser, path=/TestWiki/attach
> 2015-11-25 14:05:41.799 [http-bio-8080-exec-1] DEBUG AttachmentServlet 437 -
> AttachmentServlet doPost entered
> 2015-11-25 14:05:41.799 [http-bio-8080-exec-1] DEBUG AttachmentServlet 490 -
> AttachmentServlet upload entered
> 2015-11-25 14:05:41.820 [http-bio-8080-exec-1] DEBUG AttachmentServlet 509 -
> AttachmentServlet upload; starting try
> 2015-11-25 14:05:41.887 [http-bio-8080-exec-1] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.888 [http-bio-8080-exec-1] DEBUG WikiContext 248 -
> Creating WikiContext for session ID=8974D02E77F76467ACB66B0EAC09C4D7;
> target=Main
> 2015-11-25 14:05:41.892 [http-bio-8080-exec-1] DEBUG AttachmentServlet 515 -
> AttachmentServlet upload; after wikiContext req=
> 2015-11-25 14:05:41.903 [http-bio-8080-exec-1] DEBUG AttachmentServlet 535 -
> AttachmentServlet upload; fileItems.size()=0
> 2015-11-25 14:05:41.903 [http-bio-8080-exec-1] DEBUG AttachmentServlet 536 -
> AttachmentServlet upload; before for loop
> 2015-11-25 14:05:41.903 [http-bio-8080-exec-1] DEBUG AttachmentServlet 579 -
> AttachmentServlet upload; after for loop
> 2015-11-25 14:05:41.903 [http-bio-8080-exec-1] DEBUG AttachmentServlet 583 -
> AttachmentServlet upload; fileItems size was 0; doing redirect to errorPage
> 2015-11-25 14:05:41.904 [http-bio-8080-exec-1] DEBUG AttachmentServlet 640 -
> AttachmentServlet upload; after multiple catch, in finally
> 2015-11-25 14:05:41.904 [http-bio-8080-exec-1] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.904 [http-bio-8080-exec-1] DEBUG AttachmentServlet 451 -
> AttachmentServlet doPost catch doing redirect
> 2015-11-25 14:05:41.904 [http-bio-8080-exec-1] DEBUG AttachmentServlet 454 -
> AttachmentServlet doPost exiting
> 2015-11-25 14:05:41.944 [http-bio-8080-exec-2] DEBUG WikiServletFilter 107 -
> Using ByteArrayResponseWrapper
> 2015-11-25 14:05:41.944 [http-bio-8080-exec-2] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.945 [http-bio-8080-exec-2] DEBUG WikiSession 851 - Custom
> com.apache.wiki.WikiSession.isIPV4Address has been entered
> 2015-11-25 14:05:41.945 [http-bio-8080-exec-2] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.945 [http-bio-8080-exec-2] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.945 [http-bio-8080-exec-2] DEBUG WikiServletFilter 164 -
> Executed security filters for user=AdminUser, path=/TestWiki/Error.jsp
> 2015-11-25 14:05:41.963 [http-bio-8080-exec-2] DEBUG SessionMonitor 117 -
> Looking up WikiSession for session ID=8974D02E77F76467ACB66B0EAC09C4D7...
> found it
> 2015-11-25 14:05:41.965 [http-bio-8080-exec-2] DEBUG WikiContext 248 -
> Creating WikiContext for session ID=8974D02E77F76467ACB66B0EAC09C4D7;
> target=Error
> 2015-11-25 14:05:41.966 [http-bio-8080-exec-2] DEBUG JSPWiki 125 - Error.jsp
> exception is:
> 2015-11-25 14:05:41.967 [http-bio-8080-exec-2] ERROR WikiTagBase 84 -
> WikiTagBase pageContext IS NOT NULL
> 2015-11-25 14:05:41.970 [http-bio-8080-exec-2] ERROR WikiTagBase 97 - Tag
> failed
> javax.servlet.jsp.JspException: WikiContext may not be NULL - serious
> internal problem!
> at org.apache.wiki.tags.WikiTagBase.doStartTag(WikiTagBase.java:90)
> at
> org.apache.jsp.Error_jsp._jspx_meth_wiki_005fMessages_005f0(Error_jsp.java:193)
>
> at org.apache.jsp.Error_jsp._jspService(Error_jsp.java:138)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
>
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>
> at org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:177)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:121)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:341)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
>
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
>
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
> 2015-11-25 14:05:41.973 [http-bio-8080-exec-2] ERROR WikiTagBase 116 - Tag
> failed, check logs: WikiContext may not be NULL - serious internal problem!
> javax.servlet.jsp.JspException: Tag failed, check logs: WikiContext may not
> be NULL - serious internal problem!
> at org.apache.wiki.tags.WikiTagBase.doStartTag(WikiTagBase.java:98)
> at
> org.apache.jsp.Error_jsp._jspx_meth_wiki_005fMessages_005f0(Error_jsp.java:193)
>
> at org.apache.jsp.Error_jsp._jspService(Error_jsp.java:138)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
>
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>
> at org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:177)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:121)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
>
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:341)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
>
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
>
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>
> at java.lang.Thread.run(Thread.java:724)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
