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