 |
 |
Hi Jimmy, I am also following this conversation, I am wondering if you consult the following about RemoteAuth Authentication, but still failed? https://prometheus.atlas-sys.com/display/illiad/RemoteAuth+Authentication Ling UIC Library On 7/11/2013 2:29 PM, Jimmy Ghaphery wrote: > 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) >>> > >