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

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.

public function __construct(
...
        \SessionHandlerInterface $sessionHandler = null
    ) {
...
        if (empty($sessionHandler)) {
            $sessionHandler = new CAS_Session_PhpSession;
        }
...
        $this->setSessionHandler($sessionHandler);

this calls session_set_save_handler and that won't work if the session is allready startet. Simple workaround would be:

public function __construct(
...
        \SessionHandlerInterface $sessionHandler = null
    ) {
...
        if (!empty($sessionHandler)) {
            $this->setSessionHandler($sessionHandler);
        }
...

Greetings Frank

I have installed a CAS server with a public domain and it works correctly. I implemented PHPCas in the same server and it works correctly too, and I was able to authenticate me on it.

Now I want to use my other public domain with different services with CAS authentication but, after login in CAS, when I redirect to these services, PHPCas tell me "Authentication failed, you were not authenticated"

I have been searching for a long time and I couldn't find any solution. What I need is to keep the CAS session between two servers.

The configuration of PHPCas authentication is:

phpCAS::client(CAS_VERSION_2_0,'example.com', 8443,'/cas', TRUE);

The url is this: http://client.com/portal.php?ticket=ST-..... so the ticket is granted, why is failiing the authentication?

The procedure is the following one:

include_once("../CAS.php"); 
//initialize phpCAS (CAS Version, CAS Server, Port, Base URI, Should phpCAS start a PHP Session?)
phpCAS::client(CAS_VERSION_2_0,'example.com', 8443,'/cas', TRUE); 
 
//For development. Prints out additional warnings. 
phpCAS::setDebug(); 
phpCAS::setVerbose(true);
 
//no SSL validation for the CAS server 
phpCAS::setNoCasServerValidation(); 
 
//force CAS authentication. 
phpCAS::forceAuthentication();

What can I do? setVerbose only tells me the PHPcas version and what CAS server is used. I don't have any logfile in /tmp (I don't know why)

Thanks!

I looked into this and found the function phpCAS::logout(); does not close the session out of the box.

Currently, it has: session_write_close(); header('Location: '.$cas_url); phpCAS::trace("Prepare redirect to : ".$cas_url);

    session_unset();
    session_destroy();

And should be: session_unset(); session_destroy(); session_write_close(); header('Location: '.$cas_url); phpCAS::trace("Prepare redirect to : ".$cas_url);

Notice the original writes out the session end before it unsets or destroys its properties. Additionally and even more alarmingly is that it redirects users before it can ever destroy the session.

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.

Hi,

I have a case where an application can provide proxy authentication with many CAS server. Thus on my application myapp.com, frontend developer is able to use multiple CAS server to point service under different CAS server.

The main problem, today, is when user1 launch widget using cas1.com server and instantiate another widget that uses cas2.com so the first session is override.

This behavior is due to the way to store auth inside session. Indeed phpCAS client stores auth inside $_SESSION['phpCAS'] so there is just one auth possible at the same time.

With parameterizable session subname we can imagine something like:

$_SESSION['phpCAS-cas1']
$_SESSION['phpCAS-cas2']

or maybe better splitting like

$_SESSION['cas1']['phpCAS']
$_SESSION['cas2']['phpCAS']

Hello, I found a way to abuse failure message from old CAS server to bypass authentication, even if latest phpCAS is used. The CAS20 validation function is like this:

//from line 3166 of https://github.com/Jasig/phpCAS/blob/master/source/CAS/Client.php
public function validateCAS20(&$validate_url,&$text_response,&$tree_response, $renew=false)
{
	//some checks
	} else if ($tree_response->getElementsByTagName("authenticationSuccess")->length != 0) {
		//success
	} else if ( $tree_response->getElementsByTagName("authenticationFailure")->length != 0) {
		//failure
	} else {//exception and stuff
}

A normal authenticationFailure message is like this:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationFailure code='INVALID_TICKET'>
    ticket 'ST-1234-d0VsoOn9nd0xEjVSnVXd' not recognized
  </cas:authenticationFailure>
</cas:serviceResponse>

In old CAS server version, it was possible to inject xml tag in the ticket so that the failure message become:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationFailure code='INVALID_TICKET'>
    ticket 'ST-1234-d0VsoOn9nd0xEjVSnVXd</cas:authenticationFailure><cas:authenticationSuccess><cas:user>admin</cas:user></cas:authenticationSuccess><cas:authenticationFailure code='INVALID_TICKET'>' not recognized
  </cas:authenticationFailure>
</cas:serviceResponse>

Now check the php code above and guess what happens: authentication success! The authenticationfailure elements are ignored.

Again, this is only possible when latest phpCas is configured to authenticate against old CAS server. Still, that does exist. Some other CAS clients might also be vulnerable, I didn't verify though. Dau Huy Ngoc from Deloitte France

phpCAS 1.3.2. Looks working. PHP 5.4.14. on phpCAS.log, Once a while, there are these errors in pair:

[21-Nov-2013 22:36:24 America/New_York] PHP Notice: Undefined index: SERVER_ADMIN in C:\inetpub\wwwroot\CAS\AuthenticationException.php on line 77 [21-Nov-2013 22:36:24 America/New_York] PHP Fatal error: Uncaught exception 'CAS_AuthenticationException' in C:\inetpub\wwwroot\CAS\Client.php:2839 Stack trace: #0 C:\inetpub\wwwroot\CAS\Client.php(1224): CAS_Client->validateCAS20('https://uwinid....', '<cas:serviceRes...', Object(DOMElement)) #1 C:\inetpub\wwwroot\CAS.php(1151): CAS_Client->isAuthenticated() #2 C:\inetpub\wwwroot\auth.php(53): phpCAS::isAuthenticated() #3 {main}

thrown in C:\inetpub\wwwroot\CAS\Client.php on line 2839

Migrated from PHPCAS-129

Description

I would like to move phpCAS along with the other cas server and clients to move to github. This allows for a more open development model much more flexibility. It would be great if everyone could simply add an opinions, votes or objections.

A jasig group already exists https://github.com/Jasig

I would like to shedule this shortly before the 1.3.0 release (pushed it back to end of october since we are still doing a lot of work) when all the branches are merged and no more major work is done. This would allow for a really easy transition.

Adam Franco added a comment - 14/Sep/11 9:49 PM

Yay!!!!!

I've been using git and GitHub for all of my PHPCAS work for years and have been automatically tracking the SVN repository there as well. See: https://github.com/adamfranco/phpcas/ I wrote a script to track the SVN repository and make nice git tags for all of the SVN tags (which come through git-svn as branches) and this script currently updates my github repository with the latest changes from SVN every 30 minutes.

I use Git hub for a lot of other projects and would love to take on the migration duties.

To do the migration, I (or anyone) can copy my Github repository to the Jasig space and I can update my git-svn scripts to keep the repository in the Jasig space in sync with SVN at first. Once we decide to start pushing directly to the Github repository the git-svn scripts will gracefully fail as its pushes for each branch become non-fast-forward. From there on out we just ignore/remove the SVN repository and keep working with Github.

While the technical aspects of the move are very easy (If granted access to the Jasig space I can move the repository and update the scripts in about 15 minutes), the bigger question is what workflow model we should use once freed from the single-workflow constraints of SVN.

Option 1: Small team with central repository, forks for new/less frequent contributors.

This is the model my team at Middlebury College uses for our development and the Kurogo project that I just started contributing to uses.

In this model a small number of trusted team members all have push access to the main repository, allowing any of them to integrate feature branches or fixes into the master. New, infrequent, or other contributors simply fork the repository, do work, push back to their repository, and then submit a pull request. One of the team members then reviews the pull request and optionally merges it into the central repository onto the master branch or a branch for further work as appropriate.

Option 2: Single maintainer with central repository, forks for all contributors.

This is the model used by the Linux kernel.

In this model a single maintainer is in charge of reviewing pull requests from all contributors and merging them into the master branch. There is more overhead for the maintainer, but also more control.

Option 3: Many contributors with central repository

This is the old SVN model were anybody wanting to contribute needs commit access. This allows the entire large team to merge fixes into the official master. It lowers the overhead for the maintainer, but has much less control over what gets in.

I guess my vote would be for option 1 or 2, just to keep a bit more review and oversight as to what is considered ready for the next release. This leverages the power of github's pull-request system for infrequent contributors, making it easy to contribute without having to grant trusted access before any work is done.

I'd be happy to work under either model 1 or 2 as you see fit, Joachim.

Adam Franco added a comment - 14/Sep/11 9:55 PM - edited

One other note, if going with the Jasig space I'd recommend renaming the 'phpCAS-Client' repository to 'phpcas' since the repository name will be the default directory name every time someone clones the repository and phpCAS has always been been known as 'phpCAS', 'phpcas', or 'phpCAS', but not 'phpCAS-Client'.

This will be much harder to change later once people start watching and forking the repository, so the name should be right from the get-go.

Joachim Fritschi added a comment - 15/Sep/11 12:09 AM - edited

I noticed the weird name already. Scott just named it like that but we should definately rename like you suggest. I would suggest 'phpcas'.

My option would really be Option 1. Single point of contact/work is not ideal in a small team like this. I guess you an me should have push access. I don't see any issues there. As long as we stick to our current mode of operation (JIRA issues, discussion etc.) i really have no objections.

Regarding the move: It seems you are much better prepared to do this merge. I'm happy to leave the work to you if you are willing There should be some docs on the wiki about the move of the main cas-server that marvin made this weekend. Can you take a look and see if we learn something from his work? There was a longer discussion around development/maintenance trees etc. I'm happy that you take the lead. I'm not that familiar with git. Most of my work was always svn but this is now shifting and i definately see the advantage of git.

I just sent scott a mail to add you on github with the appropriate permissions.

Scott Battaglia added a comment - 15/Sep/11 12:26 AM

Its already been renamed.

Adam Franco added a comment - 15/Sep/11 4:20 PM

I've read through the jasig wiki a bit and the one thing I didn't account for in my early export to Git was mapping the SVN username to git author name/email combos.

In Git, authors are referred to using a name and email, e.g.: Adam Franco [email protected]

By default (and when I exported the repository before), git-svn records authors as svn-username/hash. e.g.: adamfranco adamfranco@f5dbab47-78f9-eb45-b975-e544023573eb

While I could leave it as-is, it would probably be nice to re-do the export with proper names for contributors – just a little more work for nicer history going forward. Searching through the phpcas-devel list I think I was able to account for everyone. Does this mapping look right?

fritschi = Joachim Fritschi [email protected] adamfranco = Adam Franco [email protected] jmarchal = Julien Marchal [email protected] paubry = Pascal Aubry [email protected] selwood = Matthew Selwood [email protected] mbrooks = Matthew Brooks [email protected] olivierberger = Olivier Berger [email protected] brianxlong = Brian Long [email protected] saltybeagle = Brett Bieber [email protected]

Adam Franco added a comment - 15/Sep/11 9:10 PM

Ok, so have rebuilt a git repository from SVN using the author names above and pushed it to: https://github.com/Jasig/phpCAS

This the github repository is currently being updated every 15 minutes from SVN. I can rebuild it with different author names or other parameters and re-push it if needed. Once we start using it however, we won't want to rebuild it as all of the commit IDs would change and any clones and forks of the repository.

Try cloning it with and visualizing it in gitk by:

git clone [email protected]:Jasig/phpCAS.git   # read/write for Joachim
# or
git://github.com/Jasig/phpCAS.git    # readonly

cd phpCAS
gitk --all&

Let me know anything looks amiss.

Also Joachim, you'll want to go into your Github account settings and add your email address so that Github will associate all of your commits with your account. If you use a different email address on other projects you can add as many as needed and all will be attributed to your account.

Is there a plan for the other CAS projects to continue using JIRA/Confluence for issue tracking and wiki or move to those included in Github?

The Github issue tracker is pretty basic, but it does have support for assigning issues and adding them to milestones. One nice aspect of using it is that commits that mention issues automatically get linked into the issue comments (example) and issues and pull requests are pretty tightly integrated.

On the flip side, apparently there are JIRA plugins for working with git/github.

Joachim Fritschi added a comment - 16/Sep/11 2:04 PM

Please use [email protected] as my email. The other one does not exist any more.

I will have a more detailed look this weekend at the git repo. As far as jira goes the decision on the cas-dev mailing list was to keep jira for the cas-server. I don't know if there is any reason for or agains moving phpcas only. But i think being in one consistent issue tracker for all official clients is nice. Haven't really thought about it but i will have to check the thread again and check for the reasons to stay on jira.

Adam Franco added a comment - 16/Sep/11 2:56 PM

Joachim, I have updated the repository on Github with your correct email address.

Joachim Fritschi added a comment - 17/Sep/11 4:01 AM

Thanks, however from what i can see github assigns new commits to my account but all "old" ones are not really linked to my account.

Adam Franco added a comment - 17/Sep/11 7:51 AM

Can you describe a bit more of what you are seeing versus what you are expecting?

When I look at the commit list or a single commit the author is listed as jfritschi with a link to https://github.com/jfritschi

Joachim Fritschi added a comment - 17/Sep/11 7:58 AM

I have attached a screenshot of what i'm seeing.

Adam Franco added a comment - 17/Sep/11 7:26 PM

Ah, I see. The source code file listing isn't always showing the right thing. My guess is that this is an issue with Github as I've done a fresh clone of the repository and searched through all of the commits and 'Joachim Fritschi [email protected]' is the only name used for you. All of the commit views in Github seem to properly link to your account, as do all of the 'blame' views on any of the files that show an unlinked 'Joachim Fritschi'. It seems that only the source view's last-change author indicator is off.

I've tried deleting everything from the repository and re-uploading it, but with the same results. I sent a support email to github, hopefully they'll get back to me with a work-around or a fix for the 'Source' view. Adam Franco added a comment - 19/Sep/11 6:59 AM - edited

I received a response from Github support: "The incorrect pages will update as they fall out of the server's cache." I guess the error was on their end and will show up correctly soon.

Adam Franco added a comment - 04/Oct/11 9:07 AM

The github source view now seems to properly link up Joachim's commits. We are currently in a quiet period for a few weeks and as well Bradley Froehle submitted a pull request against the Github repository: https://github.com/Jasig/phpCAS/pull/1

This seems like as good a time as any to just stop using SVN for the trunk/master and let the Github master continue on ahead. To this end, I have merged Bradley's patch via git, so the Github master branch has now forked from the SVN trunk. I verified that my git-svn script has successfully failed updating trunk->master due to the change being non-fast-forward, while the other issue branches continue to be updated from SVN.

I'll update the wiki documentation to refer to the Github repository and submit a request to make the SVN repository read-only.

Adam Franco added a comment - 04/Oct/11 10:27 AM

I have now updated the Development documentation with detailed instructions on the [current] Github workflow: https://wiki.jasig.org/display/CASC/Developing+phpCAS

Adam Franco added a comment - 04/Oct/11 10:40 AM

I have created PHPCAS-133 for locking down the SVN repository to read-only state.

I think the migration is pretty much complete the only remaining thing I can think to do is to advertise the change on the mailing lists.

Joachim Fritschi added a comment - 26/Oct/11 2:15 PM

Shouldn't we delete the old code and just leave a note like they did for the cas3 code?

https://source.jasig.org/cas3/README.txt

You can announce the new repo if you want.

Joachim Fritschi added a comment - 26/Oct/11 2:18 PM

What about the issues tracking? People are starting to use the github issues and we should soon decide on a policy where we want to track stuff. I'm happy with the features of jira but i also see the advantages of github...

Any preference for you?

Adam Franco added a comment - 26/Oct/11 2:43 PM

I sent the email below yesterday, but it might have gotten lost in the aether. Short answer: my preference would be to move to Github for issue tracking and make full use of the integration and linking.

Deleting the code via SVN is a great idea. I'll do so in a few minutes.

I can write up an announcement and send it to the phpcas-users list. I never got approved to send to the phpcas-devel list, so if that list is still in use would you mind forwarding the message to it?

Hi Joachim,

I hope you had a relaxing vacation!

I'm not sure if you have noticed, but since we put the repository on GitHub, we have had 3 issues submitted already by users, one including a pull-request. It seems that the barriers to entry for using GitHub are lower than Jira, maybe just due to people already having GitHub accounts.

Having two issue trackers is a bit confusing though, so I would like suggest that at some point we either disable the GitHub issue queue or move to it exclusively and disable Jira.

In working with these three issues I have found the integration with the repository to be quite nice – commit ids and issue ids all become HTML links, and it is easy to associate commits with issues by including '#2' or 'gh-2' in the commit text. Based on these experiences and the increased participation I'd prefer to go with the GitHub issue tracker, but would be happy to continue using both for a while longer so that you can get a chance to try out the Github tracker.

What are your thoughts? Are there features of Jira that you would rather not give up?

Best, Adam

Adam Franco added a comment - 26/Oct/11 2:51 PM

Code is now deleted from the SVN repository: https://source.jasig.org/cas-clients/phpcas/

I'll copy over the remaining issues to the Github tracker and we can then update the wiki and announce the move of both the repository and issues at the same time.

This pull request introduces a slightly deeper XML parsing. It recursively goes through the DOM and moves the elements into array hierarchies. A second step flattens the Array before the relevant attributes are returned. Sub-elements are combined and JSON style Arrays are split.

Unfortunately there are whitespace changes in the file as well as I was trying to create a consistent sytle in the file

This fixes #316.

hi,

i try to install cas through pair but give install failed output.

downloading 1.3.6 ... Starting to download 1.3.6 (Unknown size) .....done: 68,029 bytes could not extract the package.xml file from "/tmp/pear/download/1.3.6" Download of "https://github.com/apereo/phpCAS/archive/1.3.6.tar.gz" succeeded, but it is not a valid package archive Invalid or missing remote package file install failed

any guide? i also try to install older version if it will successfully install but output with same error

When a project uses the jasig/phpcas package instead of the apereo/phpcas package, dependabot on github is unable to report the security alerts. So maybe the jasig/phpcas package should have "abandoned" status to motivate developers to migrate to the apereo/phpcas package?

There is also a lack of information on packagist.org. Only apereo/phpcas package announces security alerts : https://packagist.org/packages/apereo/phpcas https://packagist.org/packages/jasig/phpcas

In our application we initialize the CAS Client together with calling CAS_GracefullTerminationException::throwInsteadOfExiting() method and then we handle exceptions in our own fashion.

Right now the same exception CAS_GracefullTerminationException is used when the library ends its work and when there is a real error reported by a phpCAS::error() method.

I think it would be helpful for the integrators, to use a different exception for errors reported in the phpCAS::error() method.

Hi I'd like to put in a vote for support for service definitions that use Front Channel (GET instead of POST) SLO requests. See:

https://apereo.github.io/cas/6.2.x/installation/Logout-Single-Signout.html#single-logout-per-service

Currently it appears that the Client only looks for logout requests coming in as a POST param.

Thanks! Brent

Default nginx config has a host name of "_" Diff to support this is:

--- a/source/CAS/Client.php
+++ b/source/CAS/Client.php
@@ -3970,7 +3970,7 @@ class CAS_Client
         } else if (!empty($_SERVER['HTTP_X_FORWARDED_SERVER'])) {
             $server_url = $_SERVER['HTTP_X_FORWARDED_SERVER'];
         } else {
-            if (empty($_SERVER['SERVER_NAME'])) {
+            if (empty($_SERVER['SERVER_NAME']) || $_SERVER['SERVER_NAME'] == '_') {
                 $server_url = $_SERVER['HTTP_HOST'];
             } else {
                 $server_url = $_SERVER['SERVER_NAME'];

Obviously you need to fix the config sample in the examples folder as well:

--- a/docs/examples/config.example.php
+++ b/docs/examples/config.example.php
@@ -63,11 +63,13 @@ $driver_options = '';
 ///////////////////////////////////////////

 // Generating the URLS for the local cas example services for proxy testing
+$sname = (empty($_SERVER['SERVER_NAME']) || $_SERVER['SERVER_NAME']=='_' )?$_SERVER['HOST_NAME']:$_SERVER['SERVER_NAME'];
 if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') {
-    $curbase = 'https://' . $_SERVER['SERVER_NAME'];
+    $curbase = 'https://' . $sname;
 } else {
-    $curbase = 'http://' . $_SERVER['SERVER_NAME'];
+    $curbase = 'http://' . $sname;
 }
+unset($sname);
 if ($_SERVER['SERVER_PORT'] != 80 && $_SERVER['SERVER_PORT'] != 443) {
     $curbase .= ':' . $_SERVER['SERVER_PORT'];
 }

There seems to be a lot of code called in beginTrace for no reason, when debugging is turned off. That's assuming I'm not missing anything,

But even with debugging turned off, debug_backtrace and other functions are called regardless, if debugging/logging is on or off. Would it make sense for this to be a simple bool check wrapped around the begin and end trace.

Is this really needed in production, I've found it useful, especially with pgt issues, but I wonder if there are other methods that would prove more useful?