Session variables & External authentication. (Trac #562)

[elgg-gitbot]

Original ticket http://trac.elgg.org/ticket/562 on 38885616-04-21 by trac user staticred, assigned to unknown.

Elgg version: 1.1

Summary: Elgg appears to reset all session variables, making an external authentication module unworkable.

Full: I've been putting together a CAS authentication module for Elgg 1.x, based on a successful CAS authentication module I developed for Elgg 0.8. The module is based on the phpCAS library, and makes a request to an external CAS server. When integrating this library into Elgg 1.0, it enters into an infinite loop of redirecting -- sending an authentication request to CAS, which returns a successful authentication ticket.

The same block of code outside of the Elgg system returns a successful CAS login. Upon further investigation, it appears that Elgg is destroying the session between the time the user leaves Elgg and returns from CAS, obliterating the phpCAS session variables and creating a new, empty Elgg session.

The basic setup of the module is as follows:

1) New module created in ./mod (./mod/cas_auth)

2) module initialized with --- 8< --- register_elgg_event_handler('init','system','cas_auth_init'); --- 8< --- and custom action set up with --- 8< --- register_action('cas_auth/login', true, $CONFIG->pluginspath . 'cas_auth/login.php'); --- 8< ---

3) Custom login form is used to direct user credentials to CAS login page (ie: user form logs users into CAS page, instead of using Elgg's internal register_pam_handler() call. For what it's worth, the same problem occurs with the register_pam_handler() call).

4) After successfully logging into CAS and receiving a ticket, user is returned to http://elggsite.com/action/cas_auth/login, which calls the following block of code:

--- 8< --- $config = find_plugin_settings('cas_auth'); $NetUsername = authCAS($config);

    $attr = cas_ldapSearch($NetUsername);

--- 8< ---

the authCAS() function is as follows:

--- 8< --- function athCAS($config) { require_once('CAS/CAS.php'); $cas_validate=true; $cas_version=CAS_VERSION_2_0; $cas_language='english'; phpCAS::client($cas_version,$config->cashostname,(int)$config->casport,$config->casbaseuri,false); phpCAS::setLang($cas_language); phpCAS::sessionName("Elgg"); phpCAS::forceAuthentication(); $NetUsername = phpCAS::getUser(); //this stores their network user id

return $NetUsername;

}

--- 8< ---

The configuration options for the phpCAS calls are stored in the Elgg database as plugin configuration, and are retrieved without issue.

When the script reaches the call phpCAS::forceAuthentication();, it doesn't find the phpCAS session variable, and therefore redirects to the CAS server to authenticate the user.

This all works in Elgg 0.8 and 0.9, and also works when called independent of the Elgg framework. Through debugging, I've determined that the phpCAS session variables go missing at some point during Elgg's own session init cycle before it hits my code.

This is a death knell for any kind of external authentication method that relies on session variables and/or session cookies to pass along authentication. My institution is looking at upgrading to Elgg 1.x, but without the ability to integrate CAS, it's a non-starter.

[elgg-gitbot]

trac user marcus wrote on 38929356-07-21

There should be nothing that does this however you may be falling victim of the elgg_fingerprint in session_init.

[elgg-gitbot]

trac user marcin wrote on 38940186-03-19

Just to note, while developing a plugin I was able to replicate this problem.

on one page I set $_SESSION['my_var'] = 'dsds'; then depending which pages i click next, this var is lost inbetween.

[elgg-gitbot]

trac user marcin wrote on 38941658-04-24

I've added session_write_close(); just after setting SESSION var, and it helped, session var was persisted.

var seems to be lost somwhere in these functions : elgg_view_title elgg_view elgg_view_layout page_draw

what is funny though, is that it was only missing for specific content. In my case it couldnt save 233 int, others int like 18, 188, 114 were saved with no problem, really strange.

[elgg-gitbot]

trac user marcus wrote on 38999856-07-20

To be clear, specific content is getting wiped? What variable names are you using?

[elgg-gitbot]

trac user staticred wrote on 39016187-11-30

Define "content". No site content as I'd describe it (ie: data written to the screen) is affected. This effects only the $_SESSION variable.

To be more specific, the CAS authentication plugin works along the following lines. First, in order to interface with the external CAS server, a php library (phpCAS) is imported into the Elgg plugin. This library acts somewhat like a proxy for CAS authentication, checking the user against the CAS server and either passing them through to the CAS server for authentication (which returns the user back to the Elgg plugin) or reading the preexisting CAS authentication data from a cookie.

The phpCAS library makes use of an array stored in $_SESSION['phpcas'] to track the user's authentication status. Ennumerating the contents of $_SESSION in both the Elgg plugin and within engine/lib/sessions.php shows that the $_SESSION['phpcas'] is missing. The same test outside of Elgg 1.x shows the $_SESSION['phpcas'] set.

[elgg-gitbot]

trac user marcus wrote on 39027486-09-10

What I meant by "content" was referring to marcin, basically I wanted to clarify the behaviour that a $_SESSION variable was being deleted depending on the specific content inside.

[elgg-gitbot]

trac user marcin wrote on 39037346-06-26

Hi marcus,

this is a piece of code from groupprofile.php

... set_page_owner($group_guid);

if($group_guid > 0) { $_SESSION['falcon_ref'] = $group_guid; } else { $_SESSION['falcon_ref'] = 0; } // reassure that it is saved - this data was lost so we needed to save session here session_write_close(); ... problem appears when i visit group profile page (which should save the group guid int) and then go to blogs for instance. $_SESSION['falcon_ref'] is no longer there, suprisingly for some values it is persisted.

Unfortunetly I didn't save svn ver number of elgg which I was using then.

Saludos

Marcin

[elgg-gitbot]

Attachment added by trac user staticred on 39038464-06-29: cas_auth.zip

[elgg-gitbot]

trac user staticred wrote on 39038465-12-25

To help move this forward, I've attached the source for the CAS module.

[elgg-gitbot]

trac user marcus wrote on 39065158-09-16

(In [svn:2605]) Refs #562: Configuration flag to disable database sessions.

[elgg-gitbot]

trac user marcus wrote on 39065161-10-24

You could try updating to latest SVN and seeing if setting $CONFIG->use_file_sessions = true in settings.php makes any difference.

This flag disables database sessions which is the one major change elgg makes to session handling code.

[elgg-gitbot]

trac user staticred wrote on 39065632-12-28

No difference with the latest version in the subversion trunk. The session data from CAS is still destroyed with $CONFIG->use_file_sessions = true set.

[elgg-gitbot]

trac user staticred wrote on 39194278-11-05

To move this ahead a little further, it not appears that this might not be a session issue, but rather an issue of the ?ticket parameter being lost in the actions handler (when it is redirecting from /action/cas_auth/login to /mod/cas_auth/login.php). Here's debug output from the phpCAS module, which shows the ?ticket query parameter being lost somewhere between the time the CAS server returns from authentication and it arrives at the login.php file. The CAS server returns the user to http://elggsite/elgg15/action/cas_auth/login?ticket=ST-67278-NOiaHXkSfzzcsHQh2a5k. However, you can see in the phpCAS debug information that ?ticket=<...> is lost by the time it gets to login.php. I've added extra trace() calls to phpCAS to try and figure this out.

F265 .START ****** [CAS.php:398] F265 .=> phpCAS::client('2.0', 'secure3.athabascau.ca', 443, '/cas', false) [lib.php:21] F265 .| => CASClient::CASClient('2.0', false, 'secure3.athabascau.ca', 443, '/cas', false) [CAS.php:299] F265 .| <= '' F265 .<= '' F265 .=> phpCAS::forceAuthentication() [lib.php:26] F265 .| => CASClient::forceAuthentication() [CAS.php:895] F265 .| | Session: Elgg [client.php:626] F265 .| | session data: 4 [client.php:627] F265 .| | __elgg_fingerprint: 156710a08757b190ebc250830a7db77d [client.php:629] F265 .| | __elgg_session: 52253f8083309ace056c5689c74db72f [client.php:629] F265 .| | view: default [client.php:629] F265 .| | msg: Array [client.php:629] F265 .| | => CASClient::isAuthenticated() [client.php:631] F265 .| | | Entering isAuthenticated [client.php:733] F265 .| | | => CASClient::wasPreviouslyAuthenticated() [client.php:737] F265 .| | | | no user found [client.php:841] F265 .| | | <= false F265 .| | | no ticket found [client.php:771] F265 .| | <= false F265 .| | Session not authenticated. [client.php:637] F265 .| | => CASClient::redirectToCas(false) [client.php:639] F265 .| | | => CASClient::getServerLoginURL(false) [client.php:858] F265 .| | | | => CASClient::getURL() [client.php:330] F265 .| | | | | CGI Params: http://localhost/elgg15/action/cas_auth/login [client.php:2005] F265 .| | | | <= 'http://localhost/elgg15/action/cas_auth/login' F265 .| | | <= 'https://secure3.athabascau.ca:443/cas/login?service=http%3A%2F%2Flocalhost%2Felgg15%2Faction%2Fcas_auth%2Flogin' F265 .| | | exit() F265 .| | | - F265 .| | - F265 .| -

[elgg-gitbot]

trac user staticred wrote on 39194531-08-17

Solution found - posting here for reference.

The problem was due to Elgg moving the additional query parameters into the $vals array. The fix for this specific problem was to place

$_REQUEST['ticket'] = $vals[svn:1];

into the start of the login.php file so that phpCAS could find the query parameter.

[elgg-gitbot]

trac user marcus wrote on 39344508-11-29

Closed as this appears to be an isolated issue with one use case rather than a systemic problem.