It appears that the
sec_handler proc is forcing the user to log in before accessing an SSL page. Why was it designed to do this?
Here's an excerpt from the sec_handler documentation:
# If it's a secure page and not a login page, we check
# secure token (can't check login page because they aren't
# issued their secure tokens until after they pass through)
# It is important to note that the entire secure login
# system depends on these two functions
if { [ad_secure_conn_p] && ![ad_login_page] } {
# ns_log notice "OACS= sec_handler:secure but not login page"
if { [catch { set sec_token [split [ad_get_signed_cookie "ad_secure_token"] {,}] } errmsg] } {
# token is incorrect or nonexistent, so we force relogin.
# cro@ncacasi.org 2002-08-01
# but wait--does user have an ad_user_login_secure cookie?
# If so, just generate a secure token because he
# can't have that cookie unless he had logged in securely
# at some time in the past.
# So just call sec_setup_session to generate a new token.
# Otherwise, force a trip to /register
if { [catch {
set new_user_id [lindex [split [ad_get_signed_cookie "ad_user_login_secure"] {,}] 0] }] } {
# ns_log notice "OACS= sec_handler:token invalid $errmsg"
ad_returnredirect "/register/index?return_url=[ns_urlencode [ad_conn url]?[ad_conn query]]"
return filter_break
} else {
sec_setup_session $new_user_id
}
} else {
# need to check only one of the user_id and session_id
# if the cookie had been tampered.
# ns_log notice "OACS= sec_handler:token ok, $sec_token $session_id"
if { ![string match [lindex $sec_token 0] $session_id] } {
ad_returnredirect "/register/index?return_url=[ns_urlencode [ad_conn url]?[ad_conn query]]"
return filter_break
}
}