Jason Pruim wrote:
On Nov 28, 2007, at 12:07 PM, Stut wrote:
Jason Pruim wrote:
One of the things I have in a session variable, is a search function
through the database, and then an export to excel option. Would I be
better to store that in a cookie rather then a session variable?
Not sure what you mean by this. If you mean the results of a search
then unless your search query takes longer than your average user will
wait then you really need to optimise your search system. Duplicating
the results into a session is extremely inefficient.
However, if you mean something else could you explain it so an idiot
(that's me) can understand it.
The search results arn't stored in a session, just the search variable
(IE: What they searched for) It was the only way I could get it to
export the search results to my excel file... It may be because I have
everything in separate files that I'm running into issues...(The main
page is a separate file, as well as the edit, add, export, & search
pages) I think I need to understand more about programming basics to
figure out how to put it all in 1 file and have it work...
Sticking it all into the same file won't help. You need to think about
data between requests not between pages.
This is exactly the sort of thing where a session is overkill. The
search variable is not sensitive data, there's no need to keep it on the
server so it's an ideal candidate for a cookie. If that's all you're
using the session for then you can easily drop the session (and
therefore the session ID cookie) and just store that info in a cookie.
I tend to group stuff together to minimise the number of cookies, and if
you have anything larger than a short-ish string you need to keep that
on the server, but be sure to consider whether that information already
exists somewhere else (like in the DB) meaning you can avoid storing it
twice.
Remember that data gets sent by the browser with each request, so keep
it relatively small. Also bear in mind that the client (human or
browser) can change the contents of a cookie at any time so you need to
re-validate them on every page request. If you need to verify the
contents of a cookie from request to request you can a) encrypt it, or
b) add a checksum to it.
The one thing you do need to transfer from request to request is
something to identify the logged in user. This is done in the same
way sessions pass their identifier, in a cookie or in the URL. The
only difference is that you need to encrypt it to make it a bit
harder to fake. I generally include a timestamp in the encrypted
cookie so I can impose a hard limit on the lifetime of a session.
Normal rules for good encryption apply here, but bear in mind that
every single request will need to decrypt it, and potentially
encrypt it too so don't go overboard.
Of course it's possible that the app you're working on will never
need to scale beyond one machine, but I have been involved in
scaling too many sites that weren't designed to do it to not plan
for the possibility in everything I do now.
Anyway, that's why I avoid using 'sessions' wherever possible - IMHO
there are better ways to achieve the same goal for most applications.
I'll have to look more into cookies before I can comment much on the
rest of the e-mail which I shall start doing now I believe :)
Like I said it's possible you'll never need to scale beyond one
machine, or if you do maybe you're working for a company with pots of
spare cash. Having said that, IMHO being good at avoiding sessions is
a worthy skill to gain.
Definitely no pots of cash... Least not that I have found :)
Shame. We like pots of cash.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
