Attempting to access non-lowercase /cas path when logged in results in Access Denied

Hi @honzifox. I applied your patch and it did not solve this issue for me. Note that since your strtolower() is inside this block

  if (user_is_logged_in() && strtolower($path) == 'cas')

it is only going to apply to logged in users.

A few other strtolower()'s are needed. I've also applied strtolower() to the caslogout path.

The cas module redirects the browser to the cas server in it's implementation of hook_init(). The key is that _cas_force_login() must return TRUE. The most critical strtolower() is in that function:

  if (strtolower(arg(0)) == 'cas') {
    return TRUE;
  }

I'll try to address these test failures soon.

Here's a corrected patch. Thanks for the catch on "strotolower" @honzifox!

How come you guys have users hitting these paths with uppercase letters? Are your users manually entering the path?

Our policy is not to display a Login link on our sites. Displaying this link just encourages people (and bots) who shouldn't be logging into the site to attempt to login. (Of course we are using secure permissions and only CAS-authenticated users with the correct roles can administer the sites.) So we instruct our administrator to manually append "/cas" at the end of the site url to login. Occasionally they uppercase part of "cas".

This is not a huge deal, but $_SERVER['REQUEST_URI'] should be cas-insensitive and it seems to me that the cas module should not be an exception to that.

This patch is working well for us. When we role it into one of the next releases of our distribution and complete testing, we'll return her to RTBC this.

Thanks for your consideration!

$_SERVER['REQUEST_URI'] should be cas-insensitive

Should it? I thought case mattered - and that site.com/path1 and site.com/PATH1 are actually different URIs (especially to search engines). I don't see it mentioned specifically in the HTTP spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.

Drupal 7's menu router appears to ignore case which I think is the problem. There's a discussion on it here: https://www.drupal.org/node/276201. In Drupal 8 it appears fixed. If you try to change the case on an existing path to include an uppercase character, for example, it will give you a 404 as expected.

So, I'm a little conflicted on this. Maybe another maintainer will weigh in?

Actually I was told there is an even larger discussion around this issue... have not read it yet.... since it's massive: https://www.drupal.org/node/2075889

Thanks for setting me straight on HTTP path case sensitivity. Since my world is so Drupal-centric right now I was wrongly assuming things based on menu router behavior.

I think the basic question for the CAS module is "Is there harm in the /cas path being case-insensitive." I'll try to peruse the bigger discussions for a more thorough understanding of the big picture soon.

Paths are case-sensitive in http; so I am not really inclined to make any special considerations in the module and leave it in the hands of whatever Drupal's routing decides.

So after some more thoughts, maybe we should make this change, at least for D7? Basically, D7's menu router in case insensitive, so going to /cas, /CAS, or /caS will all trigger our path handler. Therefore, we should make sure all of our PHP that checks if the user is on this path works, regardless of case.

So, now I think I'm OK w/ this patch.

@Yalet: The reason I was inspired to patch this is that current cas module behavior is not consistent with Drupal menu router behavior. Basic menu router paths are case insensitive: https://ethics.berkeley.edu/report-problem functions the same as https://ethics.berkeley.edu/Report-problem. But /cas does not function the same as /CaS -- unless you apply this patch.

Ok, yeah I got confused; this makes total sense to me.