+1 I've read the phpCAS log and it appears that sessions is not handled correctly : - it may be the client (you can track this as Rich said)- it may be the server... is http server user authorized to store PHP sessions to configured directory ?
Notice : PHP CAS client does modify the session ID to match Ticket ID in order to handle correctly Single Sign Out requests made by CAS server.
Rgds. Le 07/07/2011 02:49, Rich Renomeron (TCG) a écrit :
From your logs it looks like egroupware thinks each request is a new session, and so is authenticating to CAS every time. Most apps set session Ids with a cookie, so you might want to look at what's happening on the browser side with Fiddler or HttpFox and see if you're sending a session cookie or not (or if egroupware is setting one). If the session cookie is not there, check your app's configuration. CAS itself looks fine. Rich On 07/05/2011 05:24 AM, Fisher wrote:Dear All, I having trouble to get working the CAS server in my environment. At firs my environment: - all the machines are OpenVZ containers - all the machines behind nginx proxy - https have been set up The CAS server itself seems working I can access it (https) and can log in with username/password retrieved from LDAP. The application I wish to cassify is the egroupware, my browser tells me it detects redirects which are will never ends. To reduce the post size I have put the cas debug into a pastebin: http://pastebin.com/jPTSbY93 Also posted the cas server log: http://pastebin.com/CVpJBnz0 The only thing that confuses me the changing client address however I believe it should not be problem. Please advice. Thank you for your help.
-- Philippe MARASSE Service Informatique - Centre Hospitalier Henri Laborit BP 587 - 370 avenue Jacques Coeur 86021 Poitiers Cedex Tel : 05.49.44.57.19
smime.p7s
Description: S/MIME Cryptographic Signature
