Problem with 1.5 session_name

[Don Chambers]

I am experimenting with a site that will be using aMember to protect content by membership level. aMember has plugins, including one for s9y, that essentially shares login info between the two applications. Additional data resides only in the aMember database and is made available via session variables. aMember, as in pre-1.5 s9y, does not name its session, so it defaults to PHPSESSID.

S9y 1.5 introduced unique session names:

Code: Select all

    // Only set the session name, if no session has yet been issued.
    if (session_id() == '') {
        session_name('s9y_' . md5(dirname(__FILE__)));
    }

As a result of this modification to 1.5, serendipity can no longer retrieve the aMember session info.

Any ideas on how aMember's plugin for serendipity could be modified so that it will name its session the same as s9y? The response I received from aMember was that they did not believe it would be possible because "....s9y uses session_regenerate_id() function on logout and in some other cases", but that does not make much sense to me because a) we are talking session_name, not ID (or are they the same thing) and b) who cares what s9y does on logout - if logged out, we no longer need amember session info.

[garvinhicking]

Hi!

inside serendipity_config_local.inc.php you could use session_start() to initialize a custom session, then s9y shouldn't touch it.

It's correct that the amember plugin cannot do this. When s9y plugins are called, the session already exists. So you must manually initialize the session for that.

Another way would be to make amember allow custom session names to pass on initiazlization of their data structures, this could maybe help for the amember side of things. I've heard for this the first time now, but if any devs want to join in for discussion, I'd be happy/open for that!

HTH,
Garvin

[Don Chambers]

inside serendipity_config_local.inc.php you could use session_start() to initialize a custom session, then s9y shouldn't touch it.

No, this does not work.

It's correct that the amember plugin cannot do this. When s9y plugins are called, the session already exists. So you must manually initialize the session for that.

I was referring to an AMEMBER plugin for serendipity, not a s9y plugin for aMember (although I do have a sidebar plugin for aMember).... is it likely that by the time the s9y plugin is called, it is also too late because the amember session also already exists? Is there any way to change a session name after it has already started?

So far, the only way I have gotten it to work is to get my site's actual s9y session name, then manually add that to an aMember file named common.inc.php. I was hoping for a method that would work within aMember's s9y plugin so no modification is required to an amember core file.

[garvinhicking]

Hi!

inside serendipity_config_local.inc.php you could use session_start() to initialize a custom session, then s9y shouldn't touch it.

No, this does not work.

In which regard? Do you get errors? Is the session name different? Did you try to utilize a custom session name inside the config_local.inc.php file?

In that case, you might really need to add "php_value auto_prepend_file /path/to/auto_append.php" to a .htaccess file, with an auto_append.php that contains your session_start() commands.

I was referring to an AMEMBER plugin for serendipity, not a s9y plugin for aMember (although I do have a sidebar plugin for aMember).... is it likely that by the time the s9y plugin is called, it is also too late because the amember session also already exists? Is there any way to change a session name after it has already started?

Well, then if amember starts the process, and includes s9y framework, in that case it should be able to create/utlize its session, so that s9y doesn't rewrite it, because it already exists?!

Regards,
Garvin

[Don Chambers]

php_value auto_prepend_file /path/to/auto_append.php almost worked. When the username/password are submitted via a form in my sidebar, a visitor is first forwarded to a login page (/amember/login.php) and then to a final destination page, which for me is back to the site's frontpage. While on the login page, the s9y session variables are all printed to the page. When logging out, both the s9y and aMember session variables are all printed on the logout page. aMember is also unable to log the visitor out of s9y.

Also, at bottom of every page is this warning:

Code: Select all

Notice: A session had already been started - ignoring session_start() in /home/www/siteonetest/htdocs/serendipity_config.inc.php on line 16

Well, then if amember starts the process, and includes s9y framework, in that case it should be able to create/utlize its session, so that s9y doesn't rewrite it, because it already exists?!

aMember does not include the s9y framework.... their plugin merely sets the s9y sessions so that the visitor is logged into s9y with the same credentials they used to log into aMember. I can provide ftp access for you if you think it would help.

[garvinhicking]

Hi!

Sadly I don't know enough about ambemer to deduce why it cannot log out, and what it does to the session.

Code: Select all

Notice: A session had already been started - ignoring session_start() in /home/www/siteonetest/htdocs/serendipity_config.inc.php on line 16

Ah, this happens because s9y tries to reinitiate a session. You could silence it to use "@session_start()" instead, because the Notice is of no importance. We cannot silence it by default, because then when users cannot start a session with errors, they would not see those error messages.

Well, then if amember starts the process, and includes s9y framework, in that case it should be able to create/utlize its session, so that s9y doesn't rewrite it, because it already exists?!

aMember does not include the s9y framework.... their plugin merely sets the s9y sessions so that the visitor is logged into s9y with the same credentials they used to log into aMember. I can provide ftp access for you if you think it would help.

Oh. That's bad. ambember should use the s9y framework.

s9y 1.5.1 has new enryption methods for some session data, so if they don'T use the API methods to create login data, but use their own methods, this will not match/work.

Regards,
Garvin

[AseR]

Oh. That's bad. ambember should use the s9y framework.
s9y 1.5.1 has new enryption methods for some session data, so if they don'T use the API methods to create login data, but use their own methods, this will not match/work.

Garvin, we don't like to include 3rd-party framework because of some critical variables can be potentially rewritten. Ex, $config, $db etc.
So, I've copied s9y encryption code into aMember plugin.

Code: Select all

        $u = $this->get_user_by_login($user['login']); // select * from authors where username=$user['login']
        $hash = $this->get_hash($user['pass'], $u['hashtype']); //uses md5 or sha1
        if ($u['password'] != $hash)
            return;

       
        $old_name = session_name();
        $old_id = session_id();
        
        $path = $this->get_config_value('serendipityPath', 0) . "serendipity_config.inc.php";
        $path = dirname($path);
        session_name('s9y_' . md5($path));
        session_start();
        session_regenerate_id(true);

        $this->serendipity_setCookie('old_session', session_id());

        $_SESSION['serendipityUser']        = $u['username'];
        $_SESSION['serendipityPassword']    = $u['password'];
        $_SESSION['serendipityEmail']       = $u['email'];
        $_SESSION['serendipityAuthorid']    = $u['authorid'];
        $_SESSION['serendipityUserlevel']   = $u['userlevel'];
        $_SESSION['serendipityAuthedUser']  = true;
        $_SESSION['serendipityRightPublish']= $u['right_publish'];
        $_SESSION['serendipityHashType']    = $u['hashtype'];

        $this->serendipity_setCookie('userDefLang', 'en');
        $_SESSION['SERVER_GENERATED_SID']   = $_SERVER['REMOTE_ADDR'] . $_SERVER['QUERY_STRING'];

        //code from function serendipity_setAuthorToken()
        $hash = sha1(uniqid(rand(), true));
        $this->serendipity_setCookie('author_token', $hash);
        $_SESSION['author_token'] = $hash;
        
        session_name($old_name);
        session_id($old_id);
        session_start();

[Don Chambers]

Garvin has been assisting me in this matter. Here is what we have done:

1. Serendipity's core code has been modified (1.6 svn branch) to properly allow one to change session names.
2. No core amember files have been modified.
3.1 .htaccess of serendipity has been modified:

Code: Select all

php_value auto_prepend_file "/path/to/prepend/file/test-sessions.php"

3.2. my test-sessions.php file causes serendipity to use a default session name:

Code: Select all

<?php 
session_name('PHPSESSID');
session_start(); 
$_SESSION['SERVER_GENERATED_SID'] = 'ijustcalltosayifillyou';

4. .htaccess was added to aMember root folder to make aMember NOT use the same code that is prepended to serendipity, to avoid problems:

Code: Select all

php_value auto_prepend_file None
RewriteEngine Off

This all works perfectly - users are properly logged into serendipity upon successful aMember login.

Unfortunately, they are NOT logged out upon aMember logout or even when a browser is closed. This is a problem because a user could have serendipity access beyond their Amember subscription period.

When aMember developers were trying to get their plugin compatible with s9y 1.5.x, they too had a problem with logging out of serendipity. Does this email exchange provide any help (messages are shown as newest first):

----------------------------------------------------
Hello, Don.

I've modified plugin. It will set authorization Cookies with life time equals to 1 hour.
BTW, aMember will remove these Cookies on logout.
----------------------------------------------------

Yes, this is critical. Think of this: Consider a subscription period of one month. Imagine that the serendipity session also lasts a month. The aMember subscription could expire, but a user would still have access to content well beyond their subscription period.

Can you think of some way to ensure visitors do not have access to protected content beyond their subscription period?

=Don=
----------------------------------------------------

Hello, Don.

Is this critical?
Serendipity uses it's own sessions and aMember can't set or remove it.
So, I've used Cookies to make single login work but it isn't suitable for logout.

----------------------------------------------------

The login function seems to work, but not the log out. When I log out of amember, I am still logged into serendipity.
=Don=

[AseR]

Don, have you un-commented code mentioned above (which set $_SESSION variables) within plugin?

[Don Chambers]

Don, have you un-commented code mentioned above (which set $_SESSION variables) within plugin?

To which code are you referring? I HAD hacked aMember's common.inc.php file so that it would use the same session name as serendipity, but that code has been removed. We were trying to do this solely through htaccess, although I would have preferred a solution contained exclusively within aMember's serendipity plugin. Unfortunately, it appears it is too late to modify a session name by the time that plugin is called.

[Don Chambers]

CORRECTION: User is logged out of serendipity if they use the aMember logout. User is NOT logged out of serendipity, but IS logged out of aMember if they merely close their browser. I am fairly certain that when I had previously modified aMember to use serendipity's session name, closing the browser resulted in logging out of both aMember and serendipity.

I still think the best scenario, if aMember can make it work, would be for aMember to use serendipity's session naming convention due to the benefits it offers over the default php session name of PHPSESSID.

[Don Chambers]

Never heard back from aMember on the session name... but have another problem with regards to aMember, and thought I would include it here.

aMember and s9y both use smarty. Unfortunately, that seems to create a conflict the first time I hit the site for the day, which certainly suggests sessions/cookie issues:

Code: Select all

Fatal error: Cannot redeclare smarty_core_assemble_plugin_filepath() (previously declared in /htdocs/amember/smarty/core/core.assemble_plugin_filepath.php:15) in /htdocs/bundled-libs/Smarty/libs/internals/core.assemble_plugin_filepath.php on line 63

Garvin suggested once upon a time that this might need to be something that aMember needs to fix. They, however, are pushing back saying there should be no problem. I also have to wonder since it is saying "smarty_core_assemble_plugin_filepath()"... it would seem that both versions of smarty would need to declare that, no? And they certainly could not be the same....

Anyway, sorry to keep beating this dead horse, but if anyone has a suggestion, I will forward it to the aMember developers.

[garvinhicking]

Hi!

Thats strange...the s9y code has this:

Code: Select all

            if (!class_exists('Smarty')) {
                include SMARTY_DIR . 'Smarty.class.php';
            }

And this should take care of only including those Smarty files, if the "Smarty" class is not yet existing. So if any other frameworks defined smarty before serendipity, it won't load those classes.

Do you have any custom PHP code or plugin that might include the framework on its own? Do a search on "Smarty.class.php" in all files of your project to see code like that...

Regards,
Garvin

[Don Chambers]

There is only one copy of that file in aMember, which is in my /amember/smarty/ folder. I have no custom code that is attempting to load the smarty framework on its own.

The error definitely says that serendipity is trying to declare smarty_core_assemble_plugin_filepath() but aMember has already done so.

So is this something aMember needs to address, or is this something that s9y SHOULD deal with, but perhaps is not working as expected?

[garvinhicking]

Hi!

Actually, it's Smarty that is trying to do it a ssecond time. Maybe something inside the Smarty code is trying to reload its own libraries due to some function loading.

This would mean inspecting a lot of the Smarty internal code...

Regards,
Garvin