Although not very common, whatever CAS server the module uses may be only be available through an http protocol (local test instances for example).
I tried to find out a reason to why the use of https is hardcoded in the module and could only find a reference to the now unused PhpCas library in the following ticket: https://www.drupal.org/project/cas/issues/1506244
I believe it would be useful to add the cas server protocol as another configuration variable for the module.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | interdiff.txt | 3.62 KB | bkosborne |
| #7 | 2996924-7.patch | 5.57 KB | bkosborne |
| #6 | 2996924-6.patch | 4.49 KB | ieguskiza |
| #4 | 2996924-4.patch | 4.4 KB | ieguskiza |
| #2 | 2996924-2.patch | 4.4 KB | ieguskiza |
Comments
Comment #2
ieguskiza commentedI added a small patch with a possible implementation of the proposed feature.
Comment #4
ieguskiza commentedFixed the failing test.
Comment #5
bkosborneThe reason it was hardcoded is because I didn't want people to configure the module in an insecure way, but I agree that it could be useful for local testing. For that reason I think we need to display a warning message for this field that indicates that HTTP should NOT be used in production environment. The reasons are two fold:
1. Doing so implies that the CAS server doesn't have a TLS certificate, so users would be entering their credentials over HTTP which is not safe
2. This module sends an HTTP POST request to the CAS server to validate the authentication token. If that's not over HTTPS it could be intercepted.
Comment #6
ieguskiza commentedThat's a good point. Would it be enough to add a warning in the description of the field? I added a patch with it, but let me know if you where thinking of something else.
Comment #7
bkosborneFound a couple issues that I fixed (see interdiff). If tests pass I will commit.
Comment #9
bkosborne