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) >