On Fri, 12 Oct 2007, Bill Moseley wrote:

In my case, I just put the session id in the URI. Sessions never contain
sensitive info, and they expire after 5 minutes, so I'm not too worried
about the security issue.

No cookie to store a global session id?  That is, your session id is
page specific?  (Is there a term for the path that a page follows?
"Web Thread"? ;) )

That is correct. It works for the way I use sessions. I only use them for transient messages about the last action like "New entry was added" or "Thanks for your review".

If there is an error on a form submission, I stick the errors and form data in the session and redirect back to the form in question.

On reflection, I realized I could also store a user id in the session if the user is logged in and use that to further restrict viewing it, though that's probably not really necessary.

For other things I might've previously stuck in a session (like searches,
paging, etc) I just stick it in the URI, again to be RESTful. This also
has the bonus that users will be able to bookmark searches and such
easily, which is nice.

One feature I'm toying with is the "undo" action (as discussed July
25) so that after a POST and update and then a redirect I get a
message "Record updated - undo".  So that message must be shown
to the correct browser window, plus the link to the undo action has to
reference a specific undo operation.  Two windows could have
concurrent pending "undo" actions.

I'm not thrilled about the "undo" feature as some future actions may
make previous stored undo actions not possible.

I sure as heck am not going to do this for my app, but it's an interesting idea. I think the type of session use I'm doing would work for this pattern.


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/

_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/

Reply via email to