sessionWatcher (better handling of session timeouts)

[s_mack]

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

[numinix]

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?

[fwed]

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).

[s_mack]

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

[voltage]

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!

[s_mack]

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

[yellow1912]

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:
<?php echo zen_draw_hidden_field('cID', $_SESSION['customer_id']);//required for sessionWatcher?>

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

[s_mack]

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

[yellow1912]

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

[s_mack]

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