Grouper Users - Open Discussion List

[Richard James <>]

Hi,

Thanks for pointing that out Gary, that has solved the problem with the Admin 
UI, we can now successfully authenticate straight through to the UI as 
required.

For the Lite UI, I have had a look at the grouper error log for any entries 
when trying to access the Lite UI, the only error we seem to catch from 
groupers perspective is;

2010-02-04 14:17:51,471: [TP-Processor6] ERROR 
PopulateErrorAction.execute(70) - Caught '403' for 
/grouper/grouperUi/appHtml/grouper.html

I have set the logging to catch everything at the moment. We have been 
looking around the code ourselves to try and work out why its behaving like 
it is, but so far a bit of a loss.

Thanks 

Richard

>-----Original Message-----
>From: GW Brown, Information Systems and Computing
>[mailto:]
>Sent: 03 February 2010 16:18
>To: Richard James; 
>
>Subject: Re: [grouper-users] Lite UI Authentication
>
>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.retrieveSessionNavRe
>s
>> ourceBundle(GrouperUiFilter.java:96) at
>>
>edu.internet2.middleware.grouper.ui.actions.PopulateErrorAction.execute(
>P
>> opulateErrorAction.java:72) at
>>
>org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
>o
>> 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(Applica
>t
>> ionFilterChain.java:290)      at
>>
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>e
>> rChain.java:206)      at
>>
>org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc
>h
>> er.java:646)      at
>>
>org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicatio
>n
>> Dispatcher.java:438)      at
>>
>org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
>a
>> tcher.java:374)      at
>>
>org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispat
>c
>> 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:2
>9
>> 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
>