// reverse just as seen from the service. Proxies have to be defined in reverse
// from the service to the user. If a user hits service A and gets proxied via
// B to service C the list of acceptable on C would be array(B,A). The definition
// of an individual proxy can be either a string or a regexp (preg_match is used)
// that will be matched against the proxy list supplied by the cas server
// when validating the proxy tickets. The strings are compared starting from
// the beginning and must fully match with the proxies in the list.
// Example:
// phpCAS::allowProxyChain(new CAS_ProxyChain(array(
// 'https://app.example.com/'
// )));
// phpCAS::allowProxyChain(new CAS_ProxyChain(array(
// '/^https:\/\/app[0-9]\.example\.com\/rest\//',
// 'http://client.example.com/'
// )));
phpCAS::allowProxyChain(new CAS_ProxyChain(array($pgtUrlRegexp)));
// For quick testing or in certain production screnarios you might want to
// allow allow any other valid service to proxy your service. To do so, add
// the "Any" chain:
// phpcas::allowProxyChain(new CAS_ProxyChain_Any);
// THIS SETTING IS HOWEVER NOT RECOMMENDED FOR PRODUCTION AND HAS SECURITY
// IMPLICATIONS: YOU ARE ALLOWING ANY SERVICE TO ACT ON BEHALF OF A USER
// ON THIS SERVICE.
//phpcas::allowProxyChain(new CAS_ProxyChain_Any);
// force CAS authentication
phpCAS::forceAuthentication();
// at this step, the user has been authenticated by the CAS server
// and the user's login name can be read with phpCAS::getUser().
// moreover, a PGT was retrieved from the CAS server that will
// permit to gain accesses to new services.
?>