Remove default CAS server

I agree, I'm not quite sure why the default is there (or why that particular default has been chosen). I'm not sure what happens though if you enable the module and then go to /cas in the scenario where there is no default and the configuration hasn't been set. I think we need fallback logic in place to prevent initializing anything in that case as well. We should probably also consider a UI message link to the configuration page after the module is enabled, if that is possible.

The default was there because it was in the code of the person who originally contributed this module back in the Drupal 4.7 days. I have no problem with removing it.

Here's a first go. I think the actual text of the messages could stand to be improved, but this is in general what I'm thinking about here.

Ah, that broke all the tests because they relied on the default value (and then altered it after the fact). This patch includes an explicit setup step for the tests to set the server URL to be altered later.

I don't think we should be using drupal_set_message to indicate that CAS is not configured. It seems odd that normal visitors would be exposed to a site configuration mistake, and putting it where it is actually reports the message twice during forced login because of the redirects.

That's a good point. I'm alright with that, but we need to do something if the menu button for login is pressed and there is no server configured. Maybe redirecting to the same page with no message is good enough, but it seems bad.

Also, last patch was blank.

I don't think we need an on/off switch for the module, That's what the module enable disable page is for. I have in the past used the hook_requirements for this. If you set the appropriate severity, it will put the warning message on all of the admin pages until you resolve the requirement. Does that seem like a reasonable approach?

I don't know.... I'd stick with whatever seems easiest. I would agree that there maybe some places where you could wrap any"altering logic" in a test for the configuration (user login page alter seems like a good place to do this). This would be nice to preserve the user experience for stock drupal, but then doesn't the login form alteration require a configuration step in order to achieve? That is, the user login form never gets altered until to tell cas to do so on a configuration page. I would assume that we'd be requiring the cas server on that configuration page. I guess then as long as CAS doesn't alter the default end user experience by default, and we deal with any issues when validating the configuration form, drupal_set_message seems fine to me. It maybe that the real issue is that the default configuration alters the naormal user login form and that is the area we need to focus on (I just don't recall right now).

I don't have really strong opinions about this so feel free to deviate as seems best to you. (my feelings won't be hurt).