We are using phpCAS to provide single-sign-on functionality through a set of Symfony 2.1 applications. During our testing, we have noticed that requesting a secured page with an invalid ticket parameter throws a CAS_AuthenticationException instead of returning false. This leads to the page returning a 500 error and the printf statement in the exception constructor printing straight to the browser.

It seems like, if a given ticket is invalid, that isn't an error and checking authentication should simply return false instead of throwing an uncatchable exception and breaking page rendering.

Relevant portion of the stacktrace:

 in /Users/dzoltok/Sites/cls/www/vendor/sln/user-bundle/SLN/Bundle/UserBundle/lib/cas/CAS/Client.php at line 2839  -+

            } else if ( $tree_response->getElementsByTagName("authenticationFailure")->length != 0) {
                // authentication succeded, extract the error code and message
                $auth_fail_list = $tree_response->getElementsByTagName("authenticationFailure");
                throw new CAS_AuthenticationException(
                    $this, 'Ticket not validated', $validate_url,
                    false/*$no_response*/, false/*$bad_response*/,
                    $text_response,

at CAS_Client ->validateCAS20 ('https://sln.localhost/app_dev.php/serviceValidate?service=http%3A%2F%2Fcls.localhost%2Fapp_dev.php%2Fprize%2F&ticket=ST-askldjfhalsdhf', '<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationFailure code="INVALID_TICKET" /> </cas:serviceResponse>', object(DOMElement))
in /Users/dzoltok/Sites/cls/www/vendor/sln/user-bundle/SLN/Bundle/UserBundle/lib/cas/CAS/Client.php at line 1224  -+
at CAS_Client ->isAuthenticated ()
in /Users/dzoltok/Sites/cls/www/vendor/sln/user-bundle/SLN/Bundle/UserBundle/lib/cas/CAS.php at line 1151  -+
at phpCAS ::isAuthenticated ()
in /Users/dzoltok/Sites/cls/www/vendor/sln/user-bundle/SLN/Bundle/UserBundle/Entity/CASServer.php at line 146  -+

Migrated from PHPCAS-115

Description

The initialization of the table is not done by phpcas. We should include some script to do this initial table creation.

Hi,

Accented characters in Languages/French.php look really weird. Same kind of characters look OK in Languages/Spanish.php or Languages/Catalan.php but in French.php they appear to be corrupted.

This might also occur with Greek.php (even if I don't speak Greek).

Best regards,

Alexandre

Hello,
I want to disable CAS proxy on our application, but I can't find a way to do that (I'm using the latest version of phpCAS).

Hi,
i am searching for some specific informations of an imap proxy example for phpCAS.
Our webmail/imap (roundcube/dovecot) system has to be authenticated through a cas-server.
Therefore i am using rc version 0.7.2 and the cas_authentication_plugin 0.4.2.
But i am not sure with the proxy configuration, so this might be the reason why iam not getting the imap service to work with cas.

Has someone got imap proxy examples or some working imap service with cas?

Anyway my cas_debug.log says the following (mailcas is the imap and roundcube server, cas is the cas server):

28E4 .START phpCAS-1.3.1 ****************** [CAS.php:450]
28E4 .=> phpCAS::proxy('2.0', 'cas.company.de', 443, '/cas', false) [cas_authn.php:256]
28E4 .| => CAS_Client::__construct('2.0', true, 'cas.company.de', 443, '/cas', false) [CAS.php:399]
28E4 .| <= ''
28E4 .<= ''
28E4 .=> phpCAS::setFixedCallbackURL('https://mailcas.company.de/?_action=pgtcallback') [cas_authn.php:259]
28E4 .<= ''
28E4 .=> phpCAS::setPGTStorageFile('/tmp') [cas_authn.php:262]
28E4 .| => CAS_PGTStorage_File::__construct(CAS_Client, '/tmp') [Client.php:2212]
28E4 .| | => CAS_PGTStorage_AbstractStorage::__construct(CAS_Client) [File.php:119]
28E4 .| | <= ''
28E4 .| <= ''
28E4 .<= ''
28E4 .=> phpCAS::setFixedServiceURL('https://mailcas.company.de/?_action=caslogin') [cas_authn.php:269]
28E4 .<= ''
28E4 .=> phpCAS::setNoCasServerValidation() [cas_authn.php:279]
28E4 .| You have configured no validation of the legitimacy of the cas server. This is not recommended for production use. [CAS.php:1663]
28E4 .<= ''
28E4 .=> phpCAS::setServerLoginURL('') [cas_authn.php:283]
28E4 .<= ''
28E4 .=> phpCAS::setServerLogoutURL('') [cas_authn.php:284]
28E4 .<= ''
28E4 .=> phpCAS::forceAuthentication() [cas_authn.php:98]
28E4 .| => CAS_Client::forceAuthentication() [CAS.php:1100]
28E4 .| | => CAS_Client::isAuthenticated() [Client.php:1081]
28E4 .| | | => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1187]
28E4 .| | | | neither user nor PGT found [Client.php:1353]
28E4 .| | | <= false
28E4 .| | | no ticket found [Client.php:1256]
28E4 .| | <= false
28E4 .| | => CAS_Client::redirectToCas(false) [Client.php:1090]
28E4 .| | | => CAS_Client::getServerLoginURL(false, false) [Client.php:1394]
28E4 .| | | | => CAS_Client::getURL() [Client.php:326]
28E4 .| | | | <= 'https://mailcas.company.de/?_action=caslogin'
28E4 .| | | <= 'https://cas.company.de/cas/login?service=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dcaslogin'
28E4 .| | | Redirect to : https://cas.company.de/cas/login?service=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dcaslogin [Client.php:1400]
28E4 .| | | exit()
28E4 .| | | -
28E4 .| | -
28E4 .| -
8FBD .START phpCAS-1.3.1 ****************** [CAS.php:450]
8FBD .=> phpCAS::proxy('2.0', 'cas.company.de', 443, '/cas', false) [cas_authn.php:256]
8FBD .| => CAS_Client::__construct('2.0', true, 'cas.company.de', 443, '/cas', false) [CAS.php:399]
8FBD .| | Ticket 'ST-442-CbqppfBNyzclIEA17Lvu-cas' found [Client.php:868]
8FBD .| <= ''
8FBD .<= ''
8FBD .=> phpCAS::setFixedCallbackURL('https://mailcas.company.de/?_action=pgtcallback') [cas_authn.php:259]
8FBD .<= ''
8FBD .=> phpCAS::setPGTStorageFile('/tmp') [cas_authn.php:262]
8FBD .| => CAS_PGTStorage_File::__construct(CAS_Client, '/tmp') [Client.php:2212]
8FBD .| | => CAS_PGTStorage_AbstractStorage::__construct(CAS_Client) [File.php:119]
8FBD .| | <= ''
8FBD .| <= ''
8FBD .<= ''
8FBD .=> phpCAS::setFixedServiceURL('https://mailcas.company.de/?_action=caslogin') [cas_authn.php:269]
8FBD .<= ''
8FBD .=> phpCAS::setNoCasServerValidation() [cas_authn.php:279]
8FBD .| You have configured no validation of the legitimacy of the cas server. This is not recommended for production use. [CAS.php:1663]
8FBD .<= ''
8FBD .=> phpCAS::setServerLoginURL('') [cas_authn.php:283]
8FBD .<= ''
8FBD .=> phpCAS::setServerLogoutURL('') [cas_authn.php:284]
8FBD .<= ''
8FBD .=> phpCAS::forceAuthentication() [cas_authn.php:98]
8FBD .| => CAS_Client::forceAuthentication() [CAS.php:1100]
8FBD .| | => CAS_Client::isAuthenticated() [Client.php:1081]
8FBD .| | | => CAS_Client::_wasPreviouslyAuthenticated() [Client.php:1187]
8FBD .| | | | neither user nor PGT found [Client.php:1353]
8FBD .| | | <= false
8FBD .| | | CAS 2.0 ticket ST-442-CbqppfBNyzclIEA17Lvu-cas' is present [Client.php:1221] 8FBD .| | | => CAS_Client::validateCAS20('', NULL, NULL) [Client.php:1222] 8FBD .| | | | [Client.php:2736] 8FBD .| | | | => CAS_Client::getServerServiceValidateURL() [Client.php:2742] 8FBD .| | | | | => CAS_Client::getURL() [Client.php:415] 8FBD .| | | | | <= 'https://mailcas.company.de/?_action=caslogin' 8FBD .| | | | <= 'https://cas.company.de/cas/serviceValidate?service=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dcaslogin' 8FBD .| | | | => CAS_Client::_readURL('https://cas.company.de/cas/serviceValidate?service=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dcaslogin&ticket=ST-442-CbqppfBNyzclIEA17Lvu-cas&pgtUrl=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dpgtcallback', NULL, NULL, NULL) [Client.php:2751] 8FBD .| | | | | => CAS_Request_CurlRequest::sendRequest() [AbstractRequest.php:218] 8FBD .| | | | | | Response Body: 8FBD .| | | | | | <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> 8FBD .| | | | | | <cas:authenticationSuccess> 8FBD .| | | | | | <cas:user>user.name</cas:user> 8FBD .| | | | | | 8FBD .| | | | | | 8FBD .| | | | | | </cas:authenticationSuccess> 8FBD .| | | | | | </cas:serviceResponse> 8FBD .| | | | | | [CurlRequest.php:82] 8FBD .| | | | | <= true 8FBD .| | | | <= true 8FBD .| | | | => CAS_Client::_readExtraAttributesCas20(DOMNodeList) [Client.php:2802] 8FBD .| | | | | Testing for rubycas style attributes [Client.php:2912] 8FBD .| | | | <= '' 8FBD .| | | | Storing Proxy List [Client.php:2811] 8FBD .| | | | => CAS_ProxyChain_AllowedList::isProxyListAllowed(array ()) [Client.php:2814] 8FBD .| | | | | No proxies were found in the response [AllowedList.php:81] 8FBD .| | | | <= true 8FBD .| | | | => CAS_Client::_renameSession('ST-442-CbqppfBNyzclIEA17Lvu-cas') [Client.php:2845] 8FBD .| | | | | Skipping session rename since phpCAS is not handling the session. [Client.php:3172] 8FBD .| | | | <= '' 8FBD .| | | <= true 8FBD .| | | CAS 2.0 ticketST-442-CbqppfBNyzclIEA17Lvu-cas' was validated [Client.php:1223]
8FBD .| | | => CAS_Client::_validatePGT('https://cas.company.de/cas/serviceValidate?service=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dcaslogin&ticket=ST-442-CbqppfBNyzclIEA17Lvu-cas&pgtUrl=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dpgtcallback', '<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas\'> cas:authenticationSuccess cas:useruser.name/cas:user /cas:authenticationSuccess/cas:serviceResponse', DOMElement) [Client.php:1225]
8FBD .| | | | not found [Client.php:2235]
8FBD .| | | | => CAS_AuthenticationException::__construct(CAS_Client, 'Ticket validated but no PGT Iou transmitted', 'https://cas.company.de/cas/serviceValidate?service=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dcaslogin&ticket=ST-442-CbqppfBNyzclIEA17Lvu-cas&pgtUrl=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dpgtcallback', false, false, '<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas\'> cas:authenticationSuccess cas:useruser.name/cas:user /cas:authenticationSuccess/cas:serviceResponse') [Client.php:2241]
8FBD .| | | | | => CAS_Client::getURL() [AuthenticationException.php:76]
8FBD .| | | | | <= 'https://mailcas.company.de/?_action=caslogin'
8FBD .| | | | | CAS URL: https://cas.company.de/cas/serviceValidate?service=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dcaslogin&ticket=ST-442-CbqppfBNyzclIEA17Lvu-cas&pgtUrl=https%3A%2F%2Fmailcas.company.de%2F%3F_action%3Dpgtcallback [AuthenticationException.php:79]
8FBD .| | | | | Authentication failure: Ticket validated but no PGT Iou transmitted [AuthenticationException.php:80]
8FBD .| | | | | Reason: no CAS error [AuthenticationException.php:93]
8FBD .| | | | | CAS response: <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
8FBD .| | | | | cas:authenticationSuccess
8FBD .| | | | | cas:useruser.name/cas:user
8FBD .| | | | |
8FBD .| | | | |
8FBD .| | | | | /cas:authenticationSuccess
8FBD .| | | | | /cas:serviceResponse [AuthenticationException.php:100]
8FBD .| | | | | exit()

Have searched the web far and far, but couldnt get it round.
I would appreciate any hints.
Andl

Hi,
i have casified a webmail/imap system. When i authenticate via cas to the webmail/imap system everything is working fine and fast.
The system i am using is roundcube version 0.7.2, cas_authentication_plugin 0.4.2 and phpcas 1.3.1. An imapproxy for dovecot is also configured.
Now i am facing the problem that after i have logged in and have a time of inactivity in the mailbox (after several minutes) the imap connection is breaking up.
But, not always...Thats the point where i get confused.
Sometimes the connection is still there after a little delay of a few seconnds, but most of the time its breaking up.

mailcas.company.de is the webmail/imap-server.
cas.company.de is the cas server.

Has anyone got an idea on this kind of failure?

The logs of the cas server show the following after a succesful reconnection:

2012-08-09 16:38:01,153 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - ServiceTicket [ST-89-0TyHCUamcbb0jfdlFzyv-cas] does not exist.
2012-08-09 16:38:01,154 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: audit:unknown
WHAT: ST-89-0TyHCUamcbb0jfdlFzyv-cas
ACTION: SERVICE_TICKET_VALIDATE_FAILED
APPLICATION: CAS
WHEN: Thu Aug 09 16:38:01 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 16:38:03,332 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-90-BsQKFu2pluddBa7CXQI4-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 16:38:03,332 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-90-BsQKFu2pluddBa7CXQI4-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 16:38:03 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 16:38:07,485 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: audit:unknown
WHAT: ST-90-BsQKFu2pluddBa7CXQI4-cas
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS
WHEN: Thu Aug 09 16:38:07 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

The auth.log of the webmail/imap system looks like:

Aug 9 16:38:01 mailcas PAM_cas[31540]: invalid option 'debug'
Aug 9 16:38:01 mailcas PAM_cas[31540]: We use SSL as configured
Aug 9 16:38:01 mailcas PAM_cas[31540]: We connect to host cas.company.de
Aug 9 16:38:01 mailcas PAM_cas[31540]: ---- request :#012GET /cas/proxyValidate?ticket=ST-89-0TyHCUamcbb0jfdlFzyv-cas&service=imap://mailcas.company.de HTTP/1.1#012Connection: close#012Host: cas.company.de#012#012
Aug 9 16:38:01 mailcas PAM_cas[31540]: ---- response :#012HTTP/1.1 200 OK#015#012Date: Thu, 09 Aug 2012 14:38:01 GMT#015#012
Server: Apache/2.2.16 (Debian)#15#012Content-Language: en-US#015#012Content-Length: 231#015#012Connection: close#015#012Content-Type: text/plain;
charset=UTF-8#015#012#015#012<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>#012#011
<cas:authenticationFailure code='INVALID_TICKET'>#12#011#011ticket 'ST-89-0TyHCUamcbb0jfdlFzyv-cas'
not recognized#012#011/cas:authenticationFailure#012/cas:serviceResponse
Aug 9 16:38:01 mailcas PAM_cas[31540]: authentication failure for user 'user' : bad CAS ticket. PT=ST-89-0TyHCUamcbb0jfdlFzyv-cas
Aug 9 16:38:01 mailcas auth[31540]: pam_ldap(dovecot:auth): nslcd authentication; user=user
Aug 9 16:38:01 mailcas auth[31540]: pam_ldap(dovecot:auth): Authentication failure; user=user
Aug 9 16:38:07 mailcas auth[31540]: PAM unable to dlopen(/lib/security/pam_passwdqc.so): /lib/security/pam_passwdqc.so: cannot open shared object file: No such file or directory
Aug 9 16:38:07 mailcas auth[31540]: PAM adding faulty module: /lib/security/pam_passwdqc.so
Aug 9 16:38:07 mailcas auth[31540]: PAM unable to dlopen(/lib/security/pam_tmpdir.so): /lib/security/pam_tmpdir.so: cannot open shared object file: No such file or directory
Aug 9 16:38:07 mailcas auth[31540]: PAM adding faulty module: /lib/security/pam_tmpdir.so
Aug 9 16:38:07 mailcas PAM_cas[31540]: invalid option 'debug'
Aug 9 16:38:07 mailcas PAM_cas[31540]: We use SSL as configured
Aug 9 16:38:07 mailcas PAM_cas[31540]: We connect to host cas.company.de
Aug 9 16:38:07 mailcas PAM_cas[31540]: ---- request :#012GET /cas/proxyValidate?ticket=ST-90-BsQKFu2pluddBa7CXQI4-cas&service=imap://mailcas.company.de
HTTP/1.1#012Connection: close#012Host: cas.company.de#012#012
Aug 9 16:38:07 mailcas PAM_cas[31540]: ---- response :#012HTTP/1.1 200 OK#015#012
Date: Thu, 09 Aug 2012 14:38:07 GMT#015#012Server: Apache/2.2.16 (Debian)#15#012Content-Language: en-US#015#012
Content-Length: 298#015#012Connection: close#015#012Content-Type: text/html;
charset=UTF-8#015#012#015#012<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>#012#011cas:authenticationSuccess#012#011#011
cas:useruser/cas:user#012#012#012#011#011cas:proxies#012#012#011#011#011cas:proxyhttps://mailcas.company.de/?_action=pgtcallback/cas:proxy#012#012#011#011/cas:proxies#012#012#011/cas:authenticationSuccess#012/cas:serviceResponse
Aug 9 16:38:07 mailcas PAM_cas[31540]: USER 'user' AUTHENTICATED WITH CAS PT:ST-90-BsQKFu2pluddBa7CXQI4-cas

But when the reconnection is failing, the server logs show:

2012-08-09 15:53:24,822 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - ServiceTicket [ST-79-lJgAsbSLrHUPsFJIC9Fs-cas] does not exist.
2012-08-09 15:53:24,823 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: audit:unknown
WHAT: ST-79-lJgAsbSLrHUPsFJIC9Fs-cas
ACTION: SERVICE_TICKET_VALIDATE_FAILED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:24 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:26,482 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-80-41E7JKc2LpBlxPgUmWma-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 15:53:26,483 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-80-41E7JKc2LpBlxPgUmWma-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:26 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:32,408 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-81-77WyEIIIo7vL1nadcBlx-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 15:53:32,409 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-81-77WyEIIIo7vL1nadcBlx-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:32 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:33,382 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-82-4qNh2S3icke2awZiAd6S-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 15:53:33,383 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-82-4qNh2S3icke2awZiAd6S-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:33 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:40,734 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket [ST-83-zHDa6i0NGUYbjloAygLF-cas] for service [https://mailcas.company.de/?_task=mail&_action=login] for user [user]
2012-08-09 15:53:40,735 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: user
WHAT: ST-83-zHDa6i0NGUYbjloAygLF-cas for https://mailcas.company.de/?_task=mail&_action=login
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:40 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:41,226 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - AuthenticationHandler: org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler successfully authenticated the user which provided the following credentials: [callbackUrl: https://mailcas.company.de/?_action=pgtcallback]
2012-08-09 15:53:41,229 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - Resolved principal https://mailcas.company.de/?_action=pgtcallback
2012-08-09 15:53:41,229 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - Principal found: https://mailcas.company.de/?_action=pgtcallback
2012-08-09 15:53:41,229 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: [callbackUrl: https://mailcas.company.de/?_action=pgtcallback]
WHAT: supplied credentials: [callbackUrl: https://mailcas.company.de/?_action=pgtcallback]
ACTION: AUTHENTICATION_SUCCESS
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:41 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:41,230 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: user
WHAT: TGT-16-qUWh1p9PIOgC9YCYE0aITT7XOcC0D6J2zqFAtzUx0aqHZNAExC-cas
ACTION: PROXY_GRANTING_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:41 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:41,231 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: audit:unknown
WHAT: ST-83-zHDa6i0NGUYbjloAygLF-cas
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:41 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:41,512 INFO [org.jasig.cas.services.DefaultServicesManagerImpl] - Reloading registered services.
2012-08-09 15:53:41,513 INFO [org.jasig.cas.services.DefaultServicesManagerImpl] - Loaded 4 services.
2012-08-09 15:53:41,648 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-84-lxqrQ7NDgQ3XraUaMe5U-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 15:53:41,649 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-84-lxqrQ7NDgQ3XraUaMe5U-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:41 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:41,770 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-85-xLG3RZxxFfbkjNJcHoTk-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 15:53:41,771 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-85-xLG3RZxxFfbkjNJcHoTk-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:41 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:51,326 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-86-qOb7b9vcwx7RaZBCc6nO-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 15:53:51,328 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted proxy ticket [ST-87-DnARGllrslnfTKQ3CfvL-cas] for service [imap://mailcas.company.de] for user [user]
2012-08-09 15:53:51,329 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-86-qOb7b9vcwx7RaZBCc6nO-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:51 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

2012-08-09 15:53:51,330 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN

WHO: https://mailcas.company.de/?_action=pgtcallback
WHAT: ST-87-DnARGllrslnfTKQ3CfvL-cas for imap://mailcas.company.de
ACTION: SERVICE_TICKET_CREATED
APPLICATION: CAS
WHEN: Thu Aug 09 15:53:51 CEST 2012
CLIENT IP ADDRESS: xxx.xxxxxx.xxx
SERVER IP ADDRESS: cas.company.de

The auth.log of a failed reconnection shows:

Aug 9 15:53:24 mailcas PAM_cas[31410]: invalid option 'debug'
Aug 9 15:53:24 mailcas PAM_cas[31410]: We use SSL as configured
Aug 9 15:53:24 mailcas PAM_cas[31410]: We connect to host cas.company.de
Aug 9 15:53:24 mailcas PAM_cas[31410]: ---- request :#012GET /cas/proxyValidate?ticket=ST-79-lJgAsbSLrHUPsFJIC9Fs-cas&service=imap://mailcas.company.de
HTTP/1.1#012Connection: close#012Host: cas.company.de#012#012
Aug 9 15:53:24 mailcas PAM_cas[31410]: ---- response :#012HTTP/1.1 200 OK#015#012Date: Thu, 09 Aug 2012 13:53:24 GMT#015#012
Server: Apache/2.2.16 (Debian)#15#012Content-Language: en-US#015#012Content-Length: 231#015#012
Connection: close#015#012Content-Type: text/plain;charset=UTF-8#015#012#015#012
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>#012#011<cas:authenticationFailure code='INVALID_TICKET'>#12#011#011ticket 'ST-79-lJgAsbSLrHUPsFJIC9Fs-cas'
not recognized#012#011/cas:authenticationFailure#012/cas:serviceResponse
Aug 9 15:53:24 mailcas PAM_cas[31410]: authentication failure for user 'user' : bad CAS ticket. PT=ST-79-lJgAsbSLrHUPsFJIC9Fs-cas
Aug 9 15:53:24 mailcas auth[31410]: pam_ldap(dovecot:auth): nslcd authentication; user=user
Aug 9 15:53:24 mailcas auth[31410]: pam_ldap(dovecot:auth): Authentication failure; user=user

The autoloader in CAS quashes existing __autoload functions. There is code in the autoloader to try to handle it, but it doesn't work for me. We're on PHP 5.3.6, so there could be a problem that has been fixed in PHP.

The fix is to remove && ($_____t === false) from line 67 in Autoload.php. This is for phpCAS 1.3.0.

Migrated from PHPCAS-127

Description

The phpCAS class should only validate that the client exists all other input validation and sequence validation should be done in the CAS_Client where it is testable.

Alternatively, the phpCAS class could be made testable by allowing resetting of its variables.

Joachim Fritschi added a comment - 06/Sep/11 1:52 PM - edited

Ok sounds like a plan. But if it's possible don't move the validation code directly into the CAS_Cclient class. I would really like to start stripping this class down. 3000 lines is just a bit to much for my taste.
Maybe we can put this in some external Validator class?

My rubycas-server (1.0.1) is sending logout requests where the SAML formated field delivered in the logoutRequest parameter is urlencoded. This prevents phpCAS from parsing the SAML.

I'm not sure if rubycas is supposed to encode this field or not, but fixing in phpCAS is fairly easy.
My understanding is that urldecoding an unencoded string should be harmless.

Here is a simple proof-of-concept patch that fixes the problem for me.

Index: CAS/Client.php
===================================================================
--- CAS/Client.php      (revision 948)
+++ CAS/Client.php      (working copy)
@@ -1320,7 +1320,8 @@
                        phpCAS::trace("phpCAS can't handle logout requests if it does not manage the session.");
                }
                phpCAS::trace("Logout requested");
-               phpCAS::trace("SAML REQUEST: ".$_POST['logoutRequest']);
+               $decoded_logout_rq = urldecode($_POST['logoutRequest']);
+               phpCAS::trace("SAML REQUEST: ".$decoded_logout_rq);
                if ($check_client) {
                        if (!$allowed_clients) {
                                $allowed_clients = array( $this->getServerHostname() );
@@ -1348,7 +1349,7 @@
                        phpCAS::trace("No access control set");
                }
                // Extract the ticket from the SAML Request
-               preg_match("|<samlp:SessionIndex>(.*)</samlp:SessionIndex>|", $_POST['logoutRequest'], $tick, PREG_OFFSET_CAPTURE, 3);
+               preg_match("|<samlp:SessionIndex>(.*)</samlp:SessionIndex>|", $decoded_logout_rq, $tick, PREG_OFFSET_CAPTURE, 3);
                $wrappedSamlSessionIndex = preg_replace('|<samlp:SessionIndex>|','',$tick[0][0]);
                $ticket2logout = preg_replace('|</samlp:SessionIndex>|','',$wrappedSamlSessionIndex);
                phpCAS::trace("Ticket to logout: ".$ticket2logout);

Use case: Want to access cookies sent back from a proxied service. Some like this:

$service = phpCAS::getProxiedService(PHPCAS_PROXIED_SERVICE_HTTP_GET);
$service->setUrl('https://example.org/example_service.php'); // sends back cookies I want
$service->send();
$cookies = $service->getCookies();

The default path for the storage of these files is currently /tmp. Since both the PGT and debug log contain security relevant info they should be moved to 'session_save_path'. This should normally be a secure directory.

If anyone still wants to move it somewhere else, they are free to do so.

@adamfranco Any objections?

Some parts of the callback handling from the CAS server needs improvement. The code is not optimal which i realized while investigating #19.

The callback handling is duplicated in isAuthenticated() on top of wasPreviouslyAuthenticated(). This would skhip the rebroadcast in certain instances. This is minor bug.

I also believe that the callback might even be handled in the constructor and not in wasPreviouslyAuthenticated(). But i'm currently a bit uncertain if i'm missing something...

@adamfranco: Do you have an idea if moving the callback handling into the constructor (where the detection is already done) might pose any problem i'm currently overlooking?

It seems that maybe the session handling is screwed up in proxy mode. Any refresh on a proxied service in our example pages fails and redirects to the cas login page.

I got the origin narrowed down to one commit with a bit of bisecting: 014b453

@adamfranco: Maybe you have an idea since it's your commit. I will start chasing the bug at the end of the week.

I was planning on doing the 1.3.0 release somewhere in the near future since we are pretty much done with all the major issues i think. My soft target would be end of february.

The only open topic is the log dir issue #22 but there is little work to be done except to investigate the php docs. The other 2 issues that are earmarked for 1.3 are more unit test #6 and the few remaining style warnings #14. I guess we can postpone them for a later release since they offer no functionality for the end user anyway.

The only open work is the Changelog, an Upgrading doc and writing a release announcement. Is there anything else missing that needs to be done?

@adamfranco: Any objections or comments?

Hi,

[It's not really an issue]

I want to implement phpCAS mode proxy in my application.
Everything was ok until we put a load balancer in front of the HTTPD server.

The problem is around PGT callback URL.

In fact, interne communications between HTTPD server and Load balancer are in HTTP. However the PGT callback URL must be an HTTPS url.

So the call looks like:
https://casserver/cas/serviceValidate?ticket=ST-XXX&service=https://myapp/&pgtUrl=https://myapp/pgtCallback

So CAS Server will call load balancer with https://myapp/pgtCallbackbut this call will arrives as http://myapp/pgtCallback to the HTTPD (due to load balancing).

And phpCAS check:
//callback mode: check that phpCAS is secured if ( !$this->_isHttps() ) { phpCAS::error('CAS proxies must be secured to use phpCAS; PGT\'s will not be received from the CAS server'); }

If you have any good practices for this kind of problem, I'm interested.

Thanks

Since usernames stored as plaintext in the session, it is sufficiently easy to become any user if the attacker can execute php on the same server. Proof of concept here:

The valid proxies and loadbalancers that are put in front of a phpcas application should be filtered. Related to #45

Hello,

I have an issues with PGTStorage:

I want to create my own PGTStorage using memcached, for that I write class extended CAS_PGTStorage_AbstractStorage like CAS_PGTStorage_File and CAS_PGTStorage_Db. But when I use setPGTStorage an error occurs because

if ( !($storage instanceof CAS_PGTStorage) ) { (l.740)

And it's no more a CAS_PGTStorage but CAS_PGTStorage_Abstract.

The testsuite broke due to the autoloader changes in #51 and #52

Migrated from PHPCAS-130

Description

Since PHPCAS-109 is closed we can now work on unit tests for the authentication flow that were not possible before.

The documentation for developing phpCAS is out of date.

Namely this instruction:

Please create branches with your issue id, e.g: PHPCAS-129

The issue id's in the examples came from jira and thus do not match issues on github. So, are we supposed to use the issues numbers assigned by github or jira?

If we are using the ones from github, what happens when they collide with the ones from jira?

If we are using the ones from jira, how do we obtain and file an issue when all the links go to github?

Calling phpCAS::setDebug(false) unsets $PHPCAS_DEBUG['filename'] which in turn causes "undefined index" notice for line if ($PHPCAS_DEBUG['filename']) { in the phpCAS::log() function.

Replacing line unset($PHPCAS_DEBUG['filename']) with $PHPCAS_DEBUG['filename'] = FALSE; in the phpCAS::setDebug() function should fix the issue.

I wasn't sure for which branch to make the fix hence didn't provide a patch.

$ grep PHPCAS_VERSION CAS-1.3.0/CAS.php
define('PHPCAS_VERSION', '1.3.0+');
...

The CAS_Client is currently a giant omnibus hunk of code weighing in at 3600 lines with 1123 statements (counted with grep -P ';|{' source/CAS/Client.php | wc -l). It has been discussed in other issues that the size and complexity of this class are problems. I'm opening this issue as a place to discuss options for refactoring the CAS_Client into smaller pieces that are easier to understand and work with.

My first stab at a refactoring the CAS_client was to pull all of the code used to proxy access to services (when using the CAS 2.0 protocol) into a separate CAS_Proxy class. This reduced the CAS_client to 2800 lines/862 statements. See the branch at https://github.com/Jasig/phpCAS/tree/Split_client_and_proxy for these changes. While these changes were certainly helpful, the client still has mess of different functions for each of the different protocols we support and complex switch or if/else statements to redirect the execution flow based on which protocol is in use.

Here's an initial proposal for refactoring the CAS_Client:

• The CAS_Client becomes an abstract class that provides the overall flow-control for
  authentication as shared by all of the protocols as well as common functions such as the
  following sections from the client:
• HTML output
• Internationalization
• Storage of CURL options
• Configuration of ticket clearing and post-auth callbacks
• Methods for supplying code-flow feedback to integrators.
• Session handling
• Authentication API methods (isAuthenticated(), forceAuthentication(), etc) and user/attribute access
• redirection & logout
• Misc helper functions like _readURL()
• CAS_Client_Cas10 class extends the CAS_Client and adds support for validating CAS 1.0 tickets.
• CAS_Client_Cas20 class extends the CAS_Client and adds support for validating CAS 2.0 tickets and reading of attributes from CAS 2.0 responses.
• CAS_Client_Cas20Proxy class extends the CAS_Client_Cas20 and adds support for proxying to other back-end services.
• CAS_Client_Saml11 class extends the CAS_Client and adds support for validating SAML 1.1 tickets and reading attributes from SAML responses.
• The phpCAS::client() and phpCAS::proxy() methods would be responsible for instantiating the proper client object based on the protocol passed.

The big question: Does dividing up the client based on protocol seem like a reasonable option or can you think of a better way to slice it up?

The style fixes in #14 broke doxygen api code documentation generation. Should be a quick fix of the doxygen config file.

symfony 1.4 following the guide to install it...

Action "cas/login" does not exist.

logs show
Feb 16 10:35:00 symfony [info] {sfPatternRouting} Match route "homepage" (/) for / with parameters array ( 'module' => 'default', 'action' => 'index',)
Feb 16 10:35:00 symfony [info] {sfFilterChain} Executing filter "sfRenderingFilter"
Feb 16 10:35:00 symfony [info] {sfFilterChain} Executing filter "sfBasicSecurityFilter"
Feb 16 10:35:00 symfony [info] {sfBasicSecurityFilter} Action "default/index" requires authentication, forwarding to "cas/login"
Feb 16 10:35:00 symfony [info] {sfFrontWebController} Action "cas/login" does not exist
Feb 16 10:35:00 symfony [err] {sfError404Exception} Action "cas/login" does not exist.
Feb 16 10:35:00 symfony [info] {sfWebResponse} Send status "HTTP/1.1 404 Not Found"
Feb 16 10:35:00 symfony [info] {sfWebResponse} Send header "Content-Type: text/html; charset=utf-8"
Feb 16 10:35:00 symfony [info] {sfWebDebugLogger} Configuration 91.70 ms (7)
Feb 16 10:35:00 symfony [info] {sfWebDebugLogger} Factories 100.74 ms (1)

Running phpcs on phpcas has show a lot of coding style deficiencies. They should be corrected so that we can work on becoming a PEAR package at some point.

According to source and LICENSE, CAS is licensed under ASL 2.0

According to https://wiki.jasig.org/display/CASC/phpCAS+license phpCAS is licensed under the New BSD License

I think, this is a documentation/wiki issue which could be easily fixed.

Please also note that, according to http://www.apache.org/licenses/GPL-compatibility.html this library could not be used by GPLv2 project.

Fix remaining PEAR style warnings. Outstanding work from #14 and #25.

Method "renameSession" in Client class use service ticket (ST) for PHP sessionid creation. This method delete invalid PHP session id characters from ST before session creation :

$session_id = preg_replace('/[^\w]/', '', $ticket);
phpCAS :: trace("Session ID: ".$session_id);
session_id($session_id);

PHP session id only accept a-zA-Z09,- (http://www.php.net/manual/en/function.session-id.php) but preg_replace('/[^\w]/', '', $ticket) preserve underscore '_' (http://www.pcre.org/pcre.txt).

We use in our organisation a CAS compatible authentification portal. This CAS server create ST that may contains underscore. Those ST are rejected by phpCAS (in a GRR application instance).
Below an extract from our debug log (phpCAS 1.2.0 but still exist in Github) :

=> CASClient::renameSession('ST-AAGVnLK1pEvI5TgciG9lDQzvh*eHoZx5lVG1g*3IhiPMXwfVqp4BJ8b_') [client.php:2744]
 Session ID: STAAGVnLK1pEvI5TgciG9lDQzvheHoZx5lVG1g3IhiPMXwfVqp4BJ8b_ [client.php:826]

Error :

Warning: session_start() [function.session-start]: The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /usr/share/php/CAS/CAS client.php on line 828.

How to fix it?
"renameSession" method should delete all invalid characters before PHP session id creation. It could be done this way (diff notation from phpCAS 1.2.2) :

2976c2976
<           $session_id = preg_replace('/[^a-zA-Z0-9\,\-]/', '', $ticket);
>               $session_id = preg_replace('/[^\w]/', '', $ticket);

By the way this problem seems to exist in handleLogoutRequests method too.

Syntax problem at line 1314 generates "Undefined property"

if ($this->rebroadcast&&!isset($_POST['rebroadcast'])) => if ($this->_rebroadcast&&!isset($_POST['rebroadcast']))


Background:
phpCAS::checkAuthentication() has three parts in an IF-ELSEIF-ELSE statement.

1. The first part short-circuits out of this function, if phpCAS::isAuthenticated() returns true.
2. The second part removes the $_SESSION['phpCAS']['auth_checked'] variable when it is not needed anymore
3. The last part assigns the $_SESSION['phpCAS']['auth_checked'] variable, and an $_SESSION['phpCAS']['auth_count'] variable to decide when to check again if the user was not logged in the first time.

Problem:
When the short-circuit occurs in the first part of the IF-ELSEIF-ELSE statement, the variable $_SESSION['phpCAS']['auth_checked'] remains set when it would otherwise be unset in the second part of the IF-ELSEIF-ELSE statement.

Here is what the snapshot that I have looks like:

public function checkAuthentication()
{
    phpCAS::traceBegin();
    $res = false;
    if ( $this->isAuthenticated() ) {
        phpCAS::trace('user is authenticated');
        $res = true;
    } else if (isset($_SESSION['phpCAS']['auth_checked'])) {
        // the previous request has redirected the client to the CAS server
        // with gateway=true
        unset($_SESSION['phpCAS']['auth_checked']);
        $res = false;
    } else {
...

Solution:
Here is what the change should probably include:

public function checkAuthentication()
{
    ...
    if ( $this->isAuthenticated() ) {
        phpCAS::trace('user is authenticated');
        /* Here is where the 'auth_checked' variable is removed just in case it's set. */
        /* The variable is also removed in the second part of the IF-ELSEIF-ELSE statement. */
        phpCAS::trace('Removing "auth_checked" in case it is set);
        unset($_SESSION['phpCAS']['auth_checked']);
        $res = true;
    } else if (isset($_SESSION['phpCAS']['auth_checked'])) {
...

Hello,
I found a problem with phpCAS.
If the web service on which I post data has a redirection, there is an infinite loop.
In fact, phpCAS will stop after 4 redirects, but it posts the data at each request.
phpCAS should post the data only once.
Thus, phpCAS will have only one redirection (not an infinity - the redirection is after data is posted, so if the data is only posted once, there will be one redirection).
Please fix this problem, so the data is only posted once.

To see the problem in action, replace that code from example_service_POST.php:

if (empty($_POST['favorite_color'])) {
    header('HTTP/1.1 400 Bad Request');
    print '<h1>You must post a <strong>favorite_color</strong>.</h1>';
    exit;
}

by:

if (empty($_POST['favorite_color'])) {
    header('HTTP/1.1 400 Bad Request');
    print '<h1>You must post a <strong>favorite_color</strong>.</h1>';
    exit;
}
else {
  header('Location: https://myurl/example_service_POST.php');
}

This will throw this exception:

CAS_ProxiedService_Exception: Exceeded the maximum number of redirects (3) in proxied service request. in CAS_ProxiedService_Http_Abstract->makeRequest() (line 196 of /path/to/CAS/ProxiedService/Http/Abstract.php).

Thanks.

I am using phpCAS as a client to CASify an app. When logging out directly with CAS's logout link, CAS and other applications correctly recognize that I am no longer logged in. However, applications using phpCAS continue to believe that I am authenticated.

Fix the remaining style warnings of #14. Mostly lines with more than 85 characters.

The service URL does not have to match the Get url specified by the client. Currently, it is assumed that these are the same. The patch below adds a setServiceUrl function to use to get the PT which is separate from the URL that the actual request is sent. See quick patch below.

https://github.com/greeno/phpCAS/compare/SupportDifferentServiceUrl

Let me know if I can clarify anything of if I am missing something entirely in regards to Proxy Tickets and Service URL's.

Thanks!

-Chris

We are writing an interface that queries the user id and then authenticates using either CAS, local, or openID. It would be great
if we could pass the username given to our interface to the cas login page page with something like

https:/somwhere.org/cas/login?id=kkvilekval&service=http://myservice.org/

Which would then present the user login with the form with the username field filled out.

[1] https://sites.google.com/site/oauthgoog/UXFedLogin/summary

Hello,

Recently we encountered a problem when deploying phpCAS in a production environment with the include path in other parts of our application.

On investigation we found that phpCAS is calling set_include_path at the bottom of the CAS/Autoload.php if it does not find itself on the include path.

This causes includes in other files that rely on the relative path to the file they're including to fail under certain circumstances. In addition it negatively impacts on application performance as changing the include path at runtime is inefficient.

This issue is seen when you're including folders files from below the current working directory which include files in their current working directory, when the system include path is blank.

The fix for this is to remove the calls to set_include_path in Autoload.php and to update the CAS_autoload function to reference the current library location instead.

We tried to use the following method in CAS-1.2.2 as well in the commit number in the latest github code (commit number : SHA: ec3e935)

In this case, we had the above code in client.example.com/proxy.php and the CAS server is cas.example.com. By default phpCAS constructs client.example.com/proxy.php as the pgtUrl. The process failed when the CAS server tried to validate the pgtUrl.

We finally got it working by giving a different pgtUrl, client.example.com/proxycallback.php, and using the phpCAS::setFixedCallbackURL method.

We also debugged why phpCAS default behavior does not work. Following is the apache log extract from the server that is serving client.example.com, with the working solution using a different pgtUrl.

192.168.1.21 - - [11/Jan/2012:14:10:12 -0500] "GET /proxy.php HTTP/1.1" 302 476
"-" "Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1"
192.168.1.247 - - [11/Jan/2012:14:10:37 -0500] "GET /proxycallback.php HTTP/1.1" 200 581
"-" "Java/1.6.0_24"
192.168.1.247 - - [11/Jan/2012:14:10:37 -0500] "GET /proxycallback.php?pgtIou=PGTIOU-22-ndDLo0Zs4JIeeDFrXNK9-cas&pgtId=TGT-60-BOmnxU0OvQkcyexOMBvbXYdOcZwiapSERiAjvDMw4nwncOxP75-cas HTTP/1.1" 200 294 "-" "Java/1.6.0_24"
192.168.1.21 - - [11/Jan/2012:14:10:36 -0500] "GET /proxy.php?ticket=ST-56-zDai54pHmOoZN9IdDdZW-cas HTTP/1.1" 200 229 "https://cas.example.com:8443/cas/login?service=https%3A%2F%2Fclient.example.com%2Fproxy.php" "Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

The first call is where my browser tries to access the proxy.php. It redirects me to the CAS server, where I provide my login credentials. Then CAS server tries to validate the pgtUrl. This is where the bug is. If CAS server calls back proxy.php as in the default behavior of phpCAS, phpCAS would redirect back to the CAS server to login. why? because phpCAS isAuthenticated() method return false. Since phpCAS has not received any service ticket back from the CAS server isAuthenticated() returning false is justifiable. As I see there are two solutions

1. Use a different fixed pgtUrl (proxycallback.php) as we did. The script at this URL retrieved the pgtId and pgtIou and saved to the pgt storage. Later when CAS calls the calling url (proxy.php) with the pgtIou , the pgtId is present in the pgt storage for the next steps.

2. Modify phpCAS to return a 200 response, bypassing every other code when the CAS server simply calls it to validate the pgtUrl.

May be there is a configuration we are missing. But we have phpCAS working using both the above two solutions. Please let us know if it is just a missing configuration or what we are reporting is a known issue.

Migrated from PHPCAS-121

Description

Implement some kind of connection caching for imap. It should be possible to cache the opened streams somehow. PHP5 should support this (like for DBs). I have to investigate this and implement a solution.

Hi,

I don't know if it's possible right now, but I didn't find anything.
It should be necessary to have an option that disable SSL support on phpCAS client, so the client must be redirected to http://cas.server.com/ instead of https when forceAuthenticate is called.

The getter for attribute _start_session of class CASClient has the same code as the setter:

public function getStartSession($session)
{
    $this->_start_session = session;
}

should be:

public function getStartSession()
{
    return $this->_start_session;
}

The session management needs an abstraction with an interface to allow it to be better integrated in to existing applications that have their own session management.

The patch #58 broke a few of the testcases.

Going beyond the debug logging, implement routine logging akin to that available in other language/platform CAS client libraries.

Perhaps adding use of a logging framework such as log4php.

represents PHPCAS-135 in GitHub issue tracker.

If curl is used with a proxy elsewhere than in phpCAS, the proxy is still use by Curl even with a new curl object

$ch = curl_init($this->url);

The workaround is add this line

     curl_setopt($ch, CURLOPT_PROXY, '');

just after

$ch = curl_init($this->url);

After updating my phpCAS from the version 1.3.1 to 1.3.2, the following error is printed on a Windows environment:

Warning: include(CAS/Client.php): failed to open stream: No such file or directory

This problem is due to the deletion of the "set_include_path" in the file "CAS/CAS/Autoload.php" (related to the tickets #51 and #52).

Migrated from PHPCAS-119

Description

An event-listener API could simplify the CAS client implementation by allowing modules to execute their own code at various points during the authentication sequence. In contrast, the phpCAS 1.x code has this sequence-dependent code injected into the various authentication functions.

This feature was first discussed and outlined in this comment on PHPCAS-100: https://issues.jasig.org/browse/PHPCAS-100?focusedCommentId=23404&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-23404

The final 1.3.0 release no longer contains the package.xml file required for installation via pear as noted in the installation guide https://wiki.jasig.org/display/CASC/phpCAS+installation+guide.

The format of the files storage had a choice between plain and xml storage. This was however never implemented fully and everything was stored plain text. This should also be reflected in the api to prevent any confusion.

I will mark the old function as deprecated and add a new one without the additional parameter.