Grouper Users - Open Discussion List

["GW Brown, Information Systems and Computing" <>]

Hi Richard,

For the Admin UI follow the instructions for the yale-cas contribution 
contrib/yale-cas-auth/README.html - starting with 'In order to prevent...'

The link there is now out-of-date - try 
<https://spaces.internet2.edu/display/GrouperWG/Customising+the+Grouper+UI>.

Unfortunately the stack trace indicates there was an error in our error 
processing so I can't tell what the original error was. If that trace comes 
from a tomcat log is there anything in grouper_error.log? There is a 
LOG.error("Caught '" + code + "' for " ... statement so I would hope 
something made it to a log.

Gary



--On 03 February 2010 10:43 -0500 

 wrote:

> Hi All,
>
> First of all just want to say great work on the latest version of
> Grouper, the auditing features and the new Lite UI will be of great
> benefit to us. Also, thanks for the release for the bug fixes as this
> solved an issue we were having when attempting to do an import via the
> GSH xml-import tool :)
>
> We are having one problem regards to the Lite UI, we have successfully
> deployed both the admin UI and the lite UI, and successfully managed to
> log in to both interfaces using Tomcat authentication. Though when we
> turn Tomcat authentication off, and protect the UI's with Shib, we are
> coming across some problems.
> If logging into the admin UI via http://<server-name>/grouper, we are
> directed to our Shib login page, once credentials are entered we are then
> directed through to the grouper home page and are presented with the root
> stem.
> Though if we attempt to login into the admin UI via
> https://<server-name>/grouper/callLogin.do or the Lite UI via
> https://<server-name>/grouper/grouperUi/appHtml/grouper.html?operation=Si
> mpleMembershipUpdate.index we encounter "HTTP Status 403 - Access to the
> requested resource has been denied." I presume this is because these are
> calling the java login functions unlike the  http://<server-name>/grouper
> URL which is redirected straight through to the home.do page. Looking
> into the logs there is the following entry;
> 28-Jan-2010 11:27:39 org.apache.catalina.core.ApplicationDispatcher invoke
> SEVERE: Servlet.service() for servlet action threw exception
> java.lang.NullPointerException
> at
> edu.internet2.middleware.grouper.ui.GrouperUiFilter.retrieveSessionNavRes
> ourceBundle(GrouperUiFilter.java:96) at
> edu.internet2.middleware.grouper.ui.actions.PopulateErrorAction.execute(P
> opulateErrorAction.java:72) at
> org.apache.struts.action.RequestProcessor.processActionPerform(RequestPro
> cessor.java:424) at
> org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2
> 26) at
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
> at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)      at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)      at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicat
> ionFilterChain.java:290)      at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte
> rChain.java:206)      at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatch
> er.java:646)      at
> org.apache.catalina.core.ApplicationDispatcher.processRequest(Application
> Dispatcher.java:438)      at
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispa
> tcher.java:374)      at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatc
> her.java:302)      at
> org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:
> 416)      at
> org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:
> 343)      at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
> 144)      at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
> 102)      at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j
> ava:109)      at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:29
> 3)      at
> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
> at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
> at
> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:6
> 98)      at
> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.j
> ava:891)      at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.
> java:690)      at java.lang.Thread.run(Thread.java:619)
>
> Not sure why this is, I guess it maybe something to do with the way the
> LoginCheckFilter works with Grouper. I have looked around the code to try
> and work this out but so far with no success, the only assumption I can
> make is that it is failing to retrieve HTTP session details when invoking
> the retrieveHttpServletRequest method. Does anyone else protect Grouper
> via Shib and has come across this problem? Or anyone have any ideas on
> how we can get round this?
> Many Thanks
>
> Richard James
> ISS Middleware Team
> Newcastle University



----------------------
GW Brown, Information Systems and Computing