sessionWatcher (better handling of session timeouts)

Odd... I didn't get an alert for Woody's post... sorry.

Yes, I'm on 1.3.7 and it works fine. And no, the functionality was not introduced in the core code so if you want it, this is the mod for you.

I've actually had 2 customers now email me appreciative that they didn't have to re-type their long review after timing out! So if 2 actually bothered to write me, you gotta wonder how many people this helps.

No bugs yet on my setup. Hopefully you have the same success.

• Steven

Somewhat unrelated, but what is the timeout length for customers not logged into the site? Can customers who have been browsing for a long time lose the products in their shopping cart without going idle?

I think this contribution does not work when the store is configured as hereafter (see admin>configuration>customer details, ZC v1.3.7) :

• Customer Shop Status - View Shop and Prices : 1 (Must login to browse)
• Customer Approval Status - Authorization Pending : 1 (Must be Authorized to Browse).

when session expires on a form page (for example "product review"), it goes back to the standard Login Page (and not the modified timeout page).

fwed - I can't confirm or deny that. I never tested with authorizations or login to browse... it would be easy for you to confirm if you are working with a test site (and you should be if you are playing around with new mods)... change those two settings back to default - change nothing else... does it work? If yes, then you are right - it doesn't work with those settings. If no, then you probably installed wrong or its conflicting with some other customization you've done.

If you are right... if it doesn't work with those settings... it won't be "fixed" anytime soon by me. Its the first time it has come up, so I think the use of those settings is pretty rare and I don't have time to look at it right now. Its probably an easy fix... duplicating some code after an "if registered" condition for example... but having never worked with a site that requires someone to register just to see what is being sold, I would have to spend too much investigative time to figure it out.

I suggest, if you do determine it doesn't work in that situation, that you not install this contrib.

• Steven

s_mack,

I wanted to thank you for this contribution. Somehow I didn't see it when you first released it. I just installed it and it works brilliantly. This is definitely one that should eventually make it into the core code.

What I particularly like is that it returns the customer to the page they were viewing before they logged in. Very, very convenient.

Keep up the great work! :thumbsup:

Thanks voltage! It sure makes sense to me. It would actually be much better as a core feature rather than a contrib, because each and every page with a form (that requires login) has to be modified to work with it. So its a "messy" contrib in terms of upgrades, at least potentially. Rolling it into the core files would be preferred.

However, it has met with some odd resistance from the core folks so I don't foresee it any time soon :) I had suggested it and they presume I'm messing with or circumventing security relating to timeouts, but if they took the time to look more carefully they'll see there's no issue there at all.

Thanks for taking the time to install it and provide feedback!

• Steven

I have just installed it as well, work nicely.

I have not had the time to check the code throughly yet, but why do we need this line in everyform:

Maybe we can work around it somehow to avoid editing many template files.

I'm sure I had a reason :)

Its because after a timeout, the system no longer has any idea which user was viewing the page with the form. With that hidden variable, when the form is submitted (now as a guest) it is stored in the database temporarily with the user id. Then, so long as after the user logs in and the user id before matches the user id after... the data can be reposted. No match, no data... this is what keeps it safe.

I doubt there is any reasonable work around that is any simpler. But I'm open to ideas.

• Steven

How about using cookie? Or hack the core code a bit, say we add a line into zen_draw_form ?

Yeah, I thought about cookies... but they are browser reliant so I didn't want to go that route.

Hacking the core code is something I avoid at all costs whereever possible because otherwise it gets killed on an upgrade. But if you want to, Go nuts :) The other danger is it then gets used in forms you may not want it used on - namely the shopping cart.

• Steven

Actually, I think cookie is a nice option, it can just holds the customers_id there, it may not work for some who disable cookies, but there are not many of those. And those who actually disable cookies, they understand the price they have to pay (trading convenience for security).

And of course, we can still allow store owners to pass the id through the form if they want to.

Using a cookie would still require either a change to the core code, or a different change to each of the form pages... so I don't see how you come out ahead.

• Steven

Remember auto_loaders and init_includes? You can have a piece of code that checks and updates the cookie everytime ZC loads a page.

Man I hate it how this site sometimes notifies me of a response, but often doesn't! Sorry, I just happened to come look... I wasn't ignoring you.

If you have a more detailed suggestion, I'd love to hear it.

If you looked at my contrib, you'll know I make use of auto_loaders and ini_includes... I don't remember specifically now, but at the time I obviously didn't see a way to make better use of it. There had to be a reason I felt it necessary to edit each file seperately... like I said, if you have some specific suggestion I'm all ears. Or better yet... go ahead!

• Steven

Hi

Anyone know if this works on latest zen cart v1.3.8a/v1.3.8?

Give it a try. Uninstall if it doesn't. I have no plans of upgrading my own site(s) at this time to test.

Looking at the list of upgrades, I see no reason why it wouldn't.

• Steven

ok, will give it a try

thanks steve

Fixed several minor errors (mainly added isset where needed:
init_sessionWatcher.php

<?php
/**
 * init_includes/init_sessionWatcher.php
 * puts customers back where they were after logging in
 * lets them know when they've timed out
 *
 * gives them the option to restore data they submitted prior to timeout (see readme)
 * 
 * @copyright Copyright 2006 s_mack
 */


if (!defined('IS_ADMIN_FLAG')) {
  die('Illegal Access');
}
if (!defined('ENABLE_SESSION_WATCHER') || ENABLE_SESSION_WATCHER == 'false') return;
if (isset($_SESSION['customer_id']) && $_SESSION['customer_id'] > 0) {
// Check if the special repost_data session variable has been created (further below) and recover
//   the post data if it has. Then destroy the saved post data.
    if (($_SESSION['repost_data'] == true) && ($_GET['main_page'] != FILENAME_TIME_OUT))
        {
        $_POST = unserialize(sessionWatcher_restorepost($_SESSION['customer_id'], $_GET['main_page']));
        unset($_POST['cID']);
        unset($_SESSION['repost_data']);
        }
} else {
// Determine if we came from a submitted form and store the data for retreival once the customer logs
//   back in. Only applies to forms that have the hidden field 'cID' set. For security, only one
//   form per customer will be stored.
    if (isset($_POST['cID']) && isset($_GET['main_page'])) {
        sessionWatcher_storePost($_POST['cID'], $_GET['main_page'], $_POST);
        
// Set the snapshot and redirect them to the TIME OUT page. This over-rides the setting of the page's
//   normal redirect but again only applies if the 'cID' hidden field has been set. The 
//   $_SESSION['show_restore_option'] variable is assigned in case you want to have your time_out
//   page only show the repost_data option on pages where it is possible
        $_SESSION['show_restore_option'] = true;
        $_SESSION['navigation']->set_snapshot();
        zen_redirect(zen_href_link(FILENAME_TIME_OUT));
    } //cID not set
// Check if the customer ok'd the re-posting of their data after a timeout. This requires the timeout
//   form to generate a 'repost_data' input set to true.
    if (isset($_POST['repost_data']) && ($_POST['repost_data'] == 'true')) {
    
        $_SESSION['repost_data'] = true;
    }
// Set the navigation snapshot on every page to return them there after a login
// This gets over-ridden on pages that have their own snapshots taken since we aren't
//   doing the redirect here (only preparing for redirect)
    if (($_GET['main_page'] != FILENAME_LOGIN) && ($_GET['main_page'] != FILENAME_LOGOFF) && ($_GET['main_page'] != FILENAME_TIME_OUT) && ($_GET['main_page'] != FILENAME_CREATE_ACCOUNT_SUCCESS) && ($_GET['main_page'] != FILENAME_CREATE_ACCOUNT)) { 
        $_SESSION['navigation']->set_snapshot();
    }
    if ($_GET['main_page'] == FILENAME_LOGOFF) {
        $_SESSION['navigation']->clear_snapshot();
    }
// End set navigation on every page
}
?>

right on, thanks. Presume you tested?

s_mack:

right on, thanks. Presume you tested?
Found no problem so far on my site, after all it's just 1-2 minor fixes.