We labored on this last Spring when we migrated to ILLiad hosted. We were
using the remote auth with CAS. The problem was intermittent. We finally
reproduced it while using the Firefox plugin Live HTTP headers where we
could specifically see CAS cookie getting dropped. For example after login
we'd see three cookies:
Cookie: s_vi=[CS]v1|...[CE]; ILLiadSessionID=J...; CASIIS=7...
and then after clicking submit for a request we'd only see two cookies with
the CAS cookie missing:
Cookie: s_vi=[CS]v1|...[CE]; ILLiadSessionID=J...

The user's request would not go through and they would be logged off. A
little different from your scenario, but in general the cookie/session
handling is buggy. We finally went to authentication through EzProxy as a
workaround, and did not have much luck engaging OCLC in a discussion about
more robust support of remote auth and CAS.

--Jimmy



On Thu, Jul 11, 2013 at 3:04 PM, Jon Gorman <[log in to unmask]>wrote:

> Actually, we tried just dumping in the default templates in a test
> yesterday.  That seemed to fix the issue at the time, but I got distracted
> by another thing going on.  This morning I was having the same issue
> again.  (This has been tricky to debug, it almost seems as if sometimes
> there's a session cookie hanging on or perhaps there's a race condition).
>
> I might try that again in a bit.
>
> One thing I haven't really gotten a good answer on is what is the
> state/point of the login forms with RemoteAuth.The impression I got from
> some conversations with OCLC was that they're not used with RemoteAuth and
> you're supposed to either to the .dll or to illiad.dll?action=10&form=10.
>
> Jon Gorman
> University of Illinois
>
>
> On Thu, Jul 11, 2013 at 1:09 PM, Durrant, Benjamin E. <
> [log in to unmask]
> > wrote:
>
> > Have you added the FORMSTATE token to the login forms? We've been running
> > into some similar issues recently and I just dug up this in the
> > documentation:
> >
> >
> https://prometheus.atlas-sys.com/display/illiad/ILLiad+Web+DLL+Tags#ILLiadWebDLLTags-TheFormstateTag
> >
> > So it sounds like this was added in 8.1, but if you've modified the pages
> > yourself you need to manually add this token into your page code.
> >
> > I haven't made the change on our pages yet, but I plan to shortly and can
> > report back.
> >
> > Ben Durrant
> > Web Developer - UST Libraries
> > http://www.stthomas.edu/libraries
> > [log in to unmask]
> > 651-962-5416
> >
> >
> >
> > -----Original Message-----
> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> > Jon Gorman
> > Sent: Thursday, July 11, 2013 12:52 PM
> > To: [log in to unmask]
> > Subject: [CODE4LIB] ILLiad - RemoteAuth and OpenURL
> >
> > Hi all,
> >
> > I was wondering if anyone has seen an issue with the ILLiad RemoteAuth
> > module and OpenURL where the remote user header doesn't seem to get
> > recognized and a session doesn't created successfully.
> >
> >
> > Here's how the flow is going:
> >
> > 1) User clicks on an OpenURL somewhere
> > 2) User hits our authentication system (CA SIteminder) login apge
> > 3) they log in
> > 4) The open url seems to get parsed
> >  into fields and the proper form selected
> > 5) The web request goes through, complains it doesn't see an http header
> > set and no cookie set and displays the content of the Logon2.html
> > page/logoff page
> > 6) However, the actual address bar is set just fine. If you hit refresh
> > (or return in the address bar in some browsers) it launches a new session
> > just fine and auto-fills out the form.
> >
> > As a workaround we're dong a javascript refresh, which works some of the
> > time.  (Will be improving that, but would like to just fix the issue)
> >
> > This might be related to another issue we're seeing where on the initial
> > login (to main menu) it never redirects to NewAuthRegistration.html or
> > ChangeUserInformation.html.  If it's a new user, they just get created w/
> > defaults.  The page always shown is Main Menu. The documentation &
> support
> > at OCLC indicate that the application is supposed to be smart enough that
> > on initial login it'll always either go to the NewAuthRegistration.html
> or
> > ChangeUserInformation.html as appropriate.
> >
> > As a workaround currently we have a landing page that links to the Main
> > Menu, NewAuthRegistration and ChangeUserInformation and advise users to
> > register if they haven't or change their info if need be.
> >
> > The OCLC forums seem on the fritz. Is there any other good places to go
> > with ILLiad questions. (I've been talking to OCLC Support, thinking more
> in
> > terms of community support)
> >
>



-- 
Jimmy Ghaphery
Head, Digital Technologies
VCU Libraries
804-827-3551