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