External Authentication

rrichards_ · Post by **rrichards_** » Tue Feb 20, 2007 12:27 pm

Here (hopefully) is the last needed patch. You can get it from http://www.cdatazone.org/files/serendip ... .patch.txt.
This includes the language support as well as the hook for a new backend_login hook. Here is a summary of the changes to language detection:
- within admin if a user saves their OWN profile, the currently used language is changed to the one submitted ONLY if their current language wasnt determined by one of the other detected methods (from REQUEST, content_negotiation, etc..)

- language detection is performed prior to login (this checks for language from REQUEST, content neg, users current language - from session - or defaults to system default). This now allows language to be set properly for event hooks during login. Lanaguage determined here is set to session for future requests.

- if user is authenticated, check if their user setting should override current language setting. This is only done if the language currently set came from session or sysetm default; otherwise the language detection should take precedence - based on origional language code. Any new language setting is set to session for future requests.

There is only one time I find the language is not refreshed properly, but this also happens in current code so should not be an issue. If a user within admin changes their current language, the language is not changed on the initial page refresh. It occurs when they go to another age (or refresh the current page again).

I am hoping all the logic was implemented correctly. If so then I plan on implementing a first rough pass at OpenID. I have an InfoCard plugin already done, but think more people would test with an OpenID plugin and I/we/(whomever wants to get involved) will need a lot of input because there are many ways to do the data integration with Serendipity and depending upon how it ends up will determine how I also do the InfoCards integration.

Rob

Post by **garvinhicking** » Tue Feb 20, 2007 1:08 pm

Hi!

Just applied your patch, and having a problem:

I have configured German as my language. When I first came to the blog (using perma-cookie to authenticate) the main language was german, but all event plugins were english.

Then I reloaded the page, and the event plugins now were german as well. That's good, I thought, so maybe the session variable just was not existing.

But then I logged out (destroyed the cookie) and logged in again, and on the welcome page, menu is in german, but event plugins are still english until I go to the next page.

In current code, after the login, all items are in german...

Do you have an idea how to fix this?

Many, many thanks for keeping up to this. You don't know how much I appreciate this. You should get yourself an amazon wishlist...

Best regards,
Garvin

rrichards_ · Post by **rrichards_** » Tue Feb 20, 2007 1:41 pm

So if I am understanding you correctly, the language only works correctly after going to a second page once the session has started? What is happening is the following:

first time you have no session, so the system default language gets used for the event plugins - as they have been loaded prior to actual authentication. You also get logged in at this point, so your preferred language from db gets set to session (but event plugins already loaded so you initially see system default lang for them). This i havent seen yet as I do not have any even plugins on my welcome page. Which ones would show here so I can make sure my env is setup better here?

next page and all following during current session are fine as the language is grabbed from session.

you then log out (session destroyed - along with preferred language). this now puts you into the same state as when you first started, so you are at square one when you go to login again.

This is unfortunately one issue I don't see anyway to fix 100% while also keeping the authentication plugins as event plugins. It is possible to allow for perma language cookies, etc..., but these won't work in every case and sometimes not desireable from the user's aspect. This kind of brings us full circle back to where we started

Possible options (we have covered many of these before):
- potentially live with the issue (might be able to provide ways to alleviate the issue - like perma lang cookies, etc.. though doubt could be solve 100% in current state)
- come up with some way to call certain functionality from plugins that doesnt involve having to load the complete plugin.
- create a new hook type
- build into system (although easiest i think this is not good in long run as it is not flexible enough to allow new auth mechanisms).

One thing to remember now is that we do have access to system defaulted config values from database, so if it is decided to live with the issue, it should be possible to be able to turn off the backend_login event completely (while not allowing external auth) it would also not cause this behavior with the language. Or maybe there is something else that can be done based on the system config.

Rob

Post by **garvinhicking** » Tue Feb 20, 2007 2:11 pm

Hi!

you initially see system default lang for them). This i havent seen yet as I do not have any even plugins on my welcome page. Which ones would show here so I can make sure my env is setup better here?

For example, use the 'Static page' plugin. This adds a menu item to the left side.

How about issuing a perma-cookie for the language? And if that cookie is not set, and the login is performed successfully on the first time, we make the s9y backend redirect/refresh the current page with a header('Location') call?

Best regards,
Garvin

Post by **mattsches** » Tue Feb 20, 2007 2:46 pm

Hi, I also applied your latest patch to the most current version from SVN (that already has your first patch included?). I can login to the admin area, but get logged out again as soon as I try to follow a link there. As for the language, I seem to have the same problem as Garvin.

One thing that's even worse: I cannot load the blog frontend anymore, because serendipity_getSessionLanguage() in serendipity_config.inc.php fails. I already double-checked if I got any of your changes wrong, and I've debugged a little, but haven't found anything yet. I'll keep you posted.

Regards,
- Mattsches

rrichards_ · Post by **rrichards_** » Tue Feb 20, 2007 3:53 pm

For language detection: The perma-cookie could work. I would see it used as taking precedance over falling back to the system default language (pre-authentiction of course). So really it would typically be used once prior to establishing the language in session. The only question is where and when should it get set the first time? For instance, if cookie is not set and language is being set based on user pref lang, then set the cookie?

Not too sure about the redirect though (dont know enough about the different areas of the appliation). Is there a specific page that a login always goes to that can be used (like the admin page?) or is it posible that a login might take a user somewhere else. Have to think about any potential GET/POST fields if the logic could be more than a simple redirect to admin page.

mattsches:
Is it possible to enable error logging (to file is easiest) and set the level to capture ALL levels? This should hopefully pinpoint where you are running into a problem.
As for getting logged out right after login, within a page you are hiting can you check the values of:
$_SESSION["author_token"]
$serendipity['COOKIE']['author_token']
$_COOKIES['author_token']

var_dump of them would be good. The logic is such that the first two listed must be the same otherwise the system assumes the session has been hijacked.

Thanks,

Rob

Post by **mattsches** » Tue Feb 20, 2007 4:56 pm

rrichards_ wrote:Is it possible to enable error logging (to file is easiest) and set the level to capture ALL levels? This should hopefully pinpoint where you are running into a problem.
As for getting logged out right after login, within a page you are hiting can you check the values of:
$_SESSION["author_token"]
$serendipity['COOKIE']['author_token']
$_COOKIES['author_token']

var_dump of them would be good. The logic is such that the first two listed must be the same otherwise the system assumes the session has been hijacked.

Ok, I now set error_reporting to all and found the right php.ini (I'm locally running XAMPP here, what a mess) to enable error logging.

The logout problem has to do with losing the session, I'll try to figure this out later.

As for your serendipity_getSessionLanguage() function: $lang as well as $serendipity['lang'] and $serendipity['detected_lang'] remain empty/null all the time, so no language is being detected at all. This is how the function looks here:

Code: Select all

function serendipity_getSessionLanguage() {
    global $serendipity;

    if (isset($_REQUEST['user_language']) && (!empty($serendipity['languages'][$_REQUEST['user_language']])) && !headers_sent()) {
        serendipity_setCookie('serendipityLanguage', $_REQUEST['user_language'], false);
    }

    if (isset($serendipity['COOKIE']['serendipityLanguage'])) {
        if ($serendipity['expose_s9y']) serendipity_header('X-Serendipity-InterfaceLangSource: Cookie');
        $lang = $serendipity['COOKIE']['serendipityLanguage'];
    } elseif (!empty($serendipity['languages'][$serendipity['GET']['lang_selected']])) {
        if ($serendipity['expose_s9y']) serendipity_header('X-Serendipity-InterfaceLangSource: GET');
        $lang = $serendipity['GET']['lang_selected'];
    } elseif (serendipity_db_bool($serendipity['lang_content_negotiation'])) {
        if ($serendipity['expose_s9y']) serendipity_header('X-Serendipity-InterfaceLangSource: Content-Negotiation');
        $lang = serendipity_detectLang();
        die();
    }

    if (isset($lang)) {
        $serendipity['detected_lang'] = $lang;
    } else {
        $lang = (isset($_SESSION['serendipityLanguage']))?$_SESSION['serendipityLanguage']:$serendipity['lang'];
        $serendipity['detected_lang'] = null;
    }

    if (!isset($serendipity['languages'][$lang])) {
        $serendipity['detected_lang'] = null;
        return $serendipity['lang'];
    } else {
        $_SESSION['serendipityLanguage'] = $lang;
        if (! is_null($serendipity['detected_lang'])) {
            if ($serendipity['expose_s9y']) serendipity_header('X-Serendipity-InterfaceLang: ' . $lang);
        }
    }
    return $lang;
}

Does it look ok to you, or did something go wrong with the patch?

- Mattsches

rrichards_ · Post by **rrichards_** » Tue Feb 20, 2007 6:38 pm

I take it the die() statement is from your debugging?
I am guessing that this has something to do with your session issue. The code in that art of the patch is a portion of working code from the current releases, with only the addition of some session testing.

What value do you happen to have after the following line?
$lang = (isset($_SESSION['serendipityLanguage']))?$_SESSION['serendipityLanguage']:$serendipity['lang'];

If set, the session should never have an empty value unless something funky is happening with the session. To check, change the (isset() to (! empty()
This is the only part that jumps out at me that could cause your symtoms. If that works then you are having session issues, which then happens to be another issue :/ (though I dont think related to my changes - just that the changes really demonstrate the problem)

Rob

Post by **mattsches** » Tue Feb 20, 2007 8:42 pm

Yes, the die() is from debugging. I guess you're right about the session problem, I will have to examine that first.

- Mattsches

Post by **garvinhicking** » Wed Feb 21, 2007 1:54 pm

Hi mattsches!

Are you by chance running squirrelmail on the same webserver? I had sporadic session loss when I ran my s9y test and squirrelmail on the same server; the sqmail session kicked my s9y session every once in a while.

Rrichards: I think the perma-cookie would be good. And implementing it like you suggested: Use it instead of fallback to default lang, if present. And set the cookie on every serendipity_authenticate_author call?

Best regards,
Garvin

Post by **mattsches** » Wed Feb 21, 2007 2:50 pm

garvinhicking wrote:Are you by chance running squirrelmail on the same webserver? I had sporadic session loss when I ran my s9y test and squirrelmail on the same server; the sqmail session kicked my s9y session every once in a while.

No, I don't. Funnily enough, I can't get session cookies to work with the latest SVN version. At first I thought my browser, my apache, my php.ini, or serendipity_setCookie() were to blame, but now I think that it's the authentication routines, but I don't have time to further narrow it down right now. Seems to me that s9y can't read my auth data after having logged in (no session cookies!), and then (re)tries an external auth method ... which of course also fails.

Post by **garvinhicking** » Wed Feb 21, 2007 3:22 pm

Hi Mattsches!

Are you using any special event plugins that are not installed from a vanilla s9y?

Maybe it's related to the first patch of rrichards; could you try the SVN version from 2006-02-19 and see if that works?

Best regards
Garvin

rrichards_ · Post by **rrichards_** » Wed Feb 21, 2007 6:07 pm

A quick test to see if there's any relation is to comment out the following block in serendipity_admin.php:
/* Check author token to insure session not hijacked */
if (! isset($_SESSION["author_token"]) || ! isset($serendipity['COOKIE']['author_token']) ||
($_SESSION["author_token"] !== $serendipity['COOKIE']['author_token'])) {
$_SESSION['serendipityAuthedUser'] = false;
@session_destroy();
}

With that commented out and things work again, add the following to see if the values get set properly and if their values are the same. If not then maybe either your session keeps changing or possibly the cookie is getting dumped by the browser???
var_dump($_SESSION["author_token"])
var_dump($serendipity['COOKIE']['author_token'])

Rob

Post by **mattsches** » Thu Feb 22, 2007 5:21 pm

Thanks for your suggestions, guys, they were a lot of help to me. Things are working quite well right now (I guess) ... here's what I did:

First of all, I went back to a vanilla S9Y 1.1.1 installation, then re-applied both of Rob's patches which broke things like before. So I followed Rob's advice and commented out the "author_token"-block -> things worked again. Tested in FF, IE, Opera.

I enabled the block again, and it still worked in IE and Opera ... but no success in FF 2.0.0.1. And now, after googling for FF cookie problems, I found out how to make it work in FF, too. In serendipity_setCookie(), I changed

Code: Select all

setcookie("serendipity[$name]", $value, time()+60*60*24*30, $serendipity['serendipityHTTPPath'], $_SERVER['HTTP_HOST'], $secure);

to

Code: Select all

setcookie("serendipity[$name]", $value, time()+60*60*24*30, $serendipity['serendipityHTTPPath']);

Seems like (my?) Firefox has problems with setting cookies for the "localhost" domain. Don't ask me what exactly causes this, but that's how it is. Also, I wonder how we can set a cookie for a HTTPS connection without giving the domain; or is the domain set implicitly? So much for debugging today ...

- Mattsches

Post by **garvinhicking** » Fri Feb 23, 2007 9:54 am

Hi mattsches!

Does it work if instead of "localhost" you configure your s9y to use the IP address?

HTH,
Garvin