 |
 |
Adding the FORMSTATE token in now seems to have fixed the OpenURL problems for us - so far. Another thing that was a gotcha for us before was we had changed the text on a login button from "Logon to ILLiad" to "Login". It turns out that text is defined in the Customization Manager and if they aren't the same in both places you can have login errors. I've also heard of issues related to http header time-zone settings. FWIW - we are using LDAP for authentication.. -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Jimmy Ghaphery Sent: Thursday, July 11, 2013 2:29 PM To: [log in to unmask] Subject: Re: [CODE4LIB] ILLiad - RemoteAuth and OpenURL 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#IL > LiadWebDLLTags-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