Engineering: feedback about LastAccessesURI & redirects

Author Message

Bertrand Dunogier

Thursday 22 July 2010 1:42:21 am

Hi developers,

we are currently refactoring our session management in order to implement session-less anonymous users & move away from forced DB based sessions in order to remove this performance bottleneck.

Two commonly used session variables are LastAccessesURI, and LastAccessedModifyingURI. These are set in index.php, after a module/view has correctly executed, and are used as fallback when it comes to redirecting the user after an action.

Using the session for this is quite bad for several reasons (doesn't cope well with multiple browser windows, unusable for sessionless users, etc).

We would like your feedback about your usage of this feature in your extensions & work, so that we figure out the best way to replace this feature, and how it should be deprecated (if deprecated at all).

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Andrew Duck

Thursday 22 July 2010 1:47:03 am

I currently use both but given the performance benefits I am open to changing this out for another method.

What alternatives are you considering at the moment as a way to replace this functionality?

Andrew Duck, Executive Director, Quiqcorp Limited
eZ Certified Developer and Trainer.
Member of the Community Project Board
http://quiqcorp.com | http://twitter.com/andrewduck

Gaetano Giunta

Thursday 22 July 2010 2:55:14 am

- putting things in session is bad. for perfs, and for tabs. Putting things into cookies is better, but unless we find a way to make it cope with multiple tabs open, it basically means you have to carry that info around appending it to your urls everywhere (argh)

- the best way to avoid having to stuff LastAccessesURI in every url is to add it as post var and make every view that redirects accept that parameter - that would be a huge boon in any case

- please make an ini setting that allows the site owner to switch back to always-use-a-session-for-anon-users if he wants. I think we have users that like to track their site visitors in a very detailed way - or extensions that just assume that a session is always there

Principal Consultant International Business
Member of the Community Project Board

Bertrand Dunogier

Thursday 22 July 2010 2:59:05 am

Well, there are two possible approaches:

  • standardize a POST variable that can be used for redirections (RedirectURI is the most likely candidate)
  • remove the need for this variable in the kernel code, so that there always is an alternative

Do you think you'll be facing situations where you can't pass a variable along ?

"

- the best way to avoid having to stuff LastAccessesURI in every url is to add it as post var and make every view that redirects accept that parameter - that would be a huge boon in any case

"

Yes, of course. RedirectURI as explained above. Making it used by default everywhere is a bit more risky, but it might be possible.

"

- please make an ini setting that allows the site owner to switch back to always-use-a-session-for-anon-users if he wants. I think we have users that like to track their site visitors in a very detailed way - or extensions that just assume that a session is always there

"

Yep, we have that. We actually have one setting that forces a session for anonymous users, and another one that forces LastAccessesURI (sigh...) & LastAccessedModifyingURI for users with a session. If you enable both, the URIs will always be stored.

Bertrand Dunogier
eZ Systems Engineering, Lyon
http://twitter.com/bdunogier
http://gplus.to/BertrandDunogier

Andrew Duck

Thursday 22 July 2010 3:10:54 am

Standardised POST variable sounds good to me.

Andrew Duck, Executive Director, Quiqcorp Limited
eZ Certified Developer and Trainer.
Member of the Community Project Board
http://quiqcorp.com | http://twitter.com/andrewduck

Jérôme Vieilledent

Thursday 22 July 2010 5:33:19 am

Same for me : Standardised POST variable, with a BC INI setting (disabled by default)

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.