Closed (fixed)
Project:
CAS
Version:
6.x-3.x-dev
Component:
CAS
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Nov 2011 at 11:33 UTC
Updated:
7 Jun 2014 at 20:59 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
metzlerd commentedWould like to know more about what you're trying to accomplish rather than how you're trying to accomplish it. In the Redirection settings under the cas settings page you can require authentication for specific pages and list any number of wild card masks for pages that you need people to go through cas to get to. Is this functionality not sufficient? If notwhat's the delta here?
Comment #2
MarcElbichon commentedCause Varnish troubles, cas_check_first (or cas_check_frequency) is disabled in our sites.
So, to do sso between sites, i'd like to send a url to log user from cas in site B only if user is connected to site A.
/cas url force authentication, so if user is not connected to site A, cas login page is printed.
What i want is to do authentication checking rather then force authentication.
So, to do this, I want to test if url contains sso=true. If right, i'd like to send cas_login_check() function. But i can't because cas_check_first is false. This could be done by adding a parameter to the function like this :
An other way is adding a new url (like /cas) to check authentication even is cas_check_first is false.
Comment #3
bfroehle commentedAbstracting from your request a bit, it seems that this issue (and the similar requests in the past) could be better dealt with by creating a more robust API for custom modules to interact with. As you describe, cas_login_check() should take some parameters, including "force authentication". I agree.
I've added a $force_authentication parameter to cas_login_check() and refactored cas_init():
Attached patch is for 7.x-1.x. Backport to 6.x-3.x should be obvious. Thoughts?
Comment #4
bfroehle commentedHmm, the patch in #3 is very hard to review. Instead please review this attached patch which is smaller because it does not dedent a large region of code.
Comment #5
bfroehle commentedAnd for 6.x-3.x, also with an easy-to-review patch leaving indenting broken. (We'll just clean up the indenting immediately prior to commit).
Comment #6
metzlerd commentedI reviewed and tested the 7.x version of this patch and it seems to perform as advertised. I was able to invoke cas_check_login from a helper module and get the desired behavior.
Comment #7
bfroehle commentedCommitted to 7.x-1.x and 6.x-3.x. Thanks for the review Dave.
Comment #8
MarcElbichon commentedI don't understand why you 've refactored cas_init().
Now you check always "force login" and "check login" even if user is connected.
Comment #9
bfroehle commentedMarc: Can you put a patch together for what you are thinking?
I agree that we should probably check if $user exists before calling those other two functions.
Comment #10
MarcElbichon commentedSuggested patch (from 3.1 version).
Comment #11
bfroehle commentedFollow-up fix:
Comment #12
bfroehle commentedCommitted to 6.x-3.x and 7.x-1.x.
Comment #13
MarcElbichon commentedWhy don't you like my patch ???
Now you check if user is connected or url is "cas" in both cas_init() and cas_login_check().
Why not to do this only in cas_login_check ?
Comment #14
bfroehle commentedHi Marc:
I certainly agree with the spirit but I think that making cas_login_check even more monolithic would be going in the wrong direction.
Instead you'll now be able to implement the check_cas path yourself in a custom module. Over time this will give other developers additional flexibility and we can include the most popular and versatile configurations back into the main CAS module.
For example:
Comment #15.0
(not verified) commentedAdd more infos