To session or NOT to session?

Anon

hi,
this is partly continuation of my earlier post "Any intelligent way of Preview before submitting?".

I have tried carrying forward the form values in to HIDDEN tags in Preview view. But only glinch in my mind is that i am writing the values twice (the printed one on the page, and the hidden ones).

Then these hidden values are passed over to Submiting to form, which stores them in DB.

Now.. i also tried the sessions instead of HIDDEN types. It works fine too, but in following article:
http://www.phpbuilder.com/columns/mattias20000105.php3?page=2

Mattias Nilsson, says:
storing data in session variables is not very efficient because PHP4 is using files to store session information.

Does it mean, storing 'fairly large' amount of text or data in sessions is not so good?

Shall i stick with HIDDEN types? although it doesnt hurt me 🙂

regards,
Daarius ...

Anon

Forgive me if I'm wrong, as I just recently learned php myself, but I've been doing some research on sessions because I'm using them on a site I'm building.

Anyway, the way I understand it, php4 (I don't know about phplib) stores session variables all in one cookie on the user's machine, as well as in a temp file somewhere on your server (this location is determined by the php config/ini). The temp file's job is to match up to the user cookie the PHPSESSID number.

(Please tell us more about the application and what data...if a user is submitting their unpublished 1000 page novel online it'd be different then just a message board or guestbook... 😉 ) If you store the data in sessions, then you know that the data will be stored in a cookie on the users system. I have looked and couldn't find out whether the temp file on the server actually mirrors the cookie (contains the data as well) or just the names of the registered variables, or possibly the cookie stores the variables and the temp file stored the data. Perhaps someone else could help enlighten us please?

Back to your problem, though...

Now, if you're simply passing these values from one form to the next (preview) to the database, and then you never have to deal with them again, then it'd probably be more efficient to go ahead and write them to the hidden data types. Alternatively, depending on the application, you could go ahead and write the data to the database after the user submits it the first time, except in the database make a 'confirm' or 'status' field and write that it isn't confirmed or something. Then, once they've previewed it and submitted, all you have to do not is go back to the database and change that one field. This last method has advantages for certain applications...if you're doing the aforementioned novel-publishing system online or even just a fancy forum, then possibly the user might want to go back to the preview page several times and update various things or rewrite, and then click save. If you do it this way, then the data is truely saved after editing/previewing, even if they haven't finalized it. If this is really really important data (really!) then say they need to check/confirm something about the data while they're previewing and their system crashes (as a certain unnamed OS does very often, and always at times when submitting really really important data like this), then their data is already stored in the database, and you can write your site to let them go back and edit it or whatever multiple times and then say finalize once they're done.

Now, that all maybe overkill if what you're truely doing is a simple guestbook, but hey, maybe someone else browsing these postings will find the discussion useful for their application. =)

I hope this was helpful in some way.
Josh

Anon

Thanks a lot for the explanation.

The system i am implementing is 'News Management System'. We have a network of reporters around the world, and they can publish the news using internet from anywhere. It enables the reporters to enter the article (all the required fields), but the main and the largest field is 'Article' textarea itself, which can be up to 100KB of text, rest all the fields are varchar(20).

so, i guess i should carry on with hidden? becuase i have to keep the security in mind too, i dont want that important info to be left on the PC they are using (may be from some caffe) or wherever.

And secondly i am only passing the value to 1 page. i.e. the add page -> Preview page -> submit to db. If user needs to edit the text, i have BACK button on the Preview page, which takes back. Upon clicking the Submit button in Preview page, the text is then saved to db.

and about the confirming and status thing to the db, do you think i should save the data when the page is previewed? and then use UPDATE query when the data is submitted?

But what if the reporter decides NOT to submit after previewing it. I mean 1 extra row will be inserted, and my primary key field article_id which is auto_increment, will step 1 higher. and that row can go waste...

hmmm ... may be HIDDEN is better, but then again session sounds good too 🙂 .. and yes, we dont have our own server. the site is hosted by some company, and so it means those temp files are made by PHP some where in /tmp and obviously i dont have access to them.. do they stay there? untill someone deletes them, of PHP removes it after end of session?

thanks a lot,
Daarius ...

Anon

You have it backwards, a cookie with a unique number is sent to the users computer and the variable values are stored in a temp file on the server. If it were the other way around it would be very insecure.

Sessions could be a good thing in this instance, but you have to change your thinking a little from the stateless put it all in the form and pass it on approach we are used to.

Anon

Hey Daarius,
Good to hear I could be of help.

Hmmm...your setup sounds really interesting...is this for a newspaper or tv station or newswire service or what?

Yes, as you brought up, you don't want to trust cookies at all if you need any sort of security, especially if your newspeople will be using public workstations. Also, I forgot to say this last time, if the variable data for sessions IS stored on the users system, I'm sure that there's a limit on the size of a cookie, and it'll probably cut off anything larger than maybe 10KB would be my guess. (I apologize for not knowing specifics on these things...but in my opinion, it makes me a better programmer/web designer if I have to actually think about what I'm doing and what the possibilities are for the client system...because of course you know that standards change and if you depend upon a standard if may just break your system)
So, the result of a cut off cookie could be simply part of the text in the article, or it may simply reject the entire cookie, or it may store it and spit up garbled results. Anyway, if your system spec. says you have to handle up to 100KB of article, you better make sure you can handle 150KB (safety margin...in case someone doesn't know the standard. =) ).

As far as one of the things you said first about writing the data twice on the page (the preview and the hidden data type), it is a valid concern: If you send your best reporter to from some far off country with a really slow connection, say (exaggerating...just to make sure we cover our bases) 300 baud, and they write this wonderful 100KB article. They must upload it the first time, then download it twice for the preview, then upload it again, that's 400+KB of data this poor guy must trickle through his 300 baud modem simply to submit his article. That would take a while, and probably cause a timeout. Now, I'm obviously exaggerating the seriousness of this situation, but if you plan for the slow, the fast will be blazingly fast, and probably work better as well.

Another user just replied as I'm writing this and told us that for sessions, the data is stored on the server and just the session id number is stored in the cookie. This makes your job a little easier, security wise. He also says you should rethink the standard submit|preview|submit approach. You might consider putting a notice right before the submit button asking them to proof-read what they wrote before submitting.) You can always do a data check and just print out the article info w/o the article itself to make sure they have the name, title, whatever correct. This will save you from having to quadruple the amount of data you send back and forth.

As far as the data mucking up the server...you must do two things: First, estimate the amount of traffic you will be getting. If you already have a site up and running, this should be easy enough. Second, figure out whether your ISP/web host will care if you have large temp files. They probably will, if you plan on having a significant number of people using the system at the same time. PHP does cleanup the old session data periodically, and if your sessions only last as far as submitting/previewing the article, then it should be fine. Make sure that after you finish writing to the database, issue a session_unregister($bigarticle); so it should clear up the space allocated for you. If your reporters log in to the system, you may want to have a session the whole time to track user preferences and such, but you only have the $bigarticle registered when you really need it.

If your webhost doesn't like what you might be doing with a bunch of big temp files, I'd recommend not using sessions, otherwise, go ahead and use them.

In php, remember that the script is executed server side, so with sessions, once you submit the article, it'll be stored in the temp file, then you can echo $bigarticle; and when they submit on the preview page or whatever you decide to use you don't need the hidden data fields because the server already has the article, it just needs to know whether it's good or not.

Regarding saving the information as unfinalized in the database, with or without sessions, but particularly without, I'd recommend, your application in mind, to save the information after the first submit and not do a preview page, but rather an update page.
What happens to the article after it's submitted to the database? Is it immediately ready for publification or sent to an editor or what? If this applies, ask a few of your reporters whether they would find a feature useful where they can go back and change/update an article after they already submitted it. I know I'm not a reporter and I don't do anything related to the newsmedia, but I suppose they might find out something or recieve a phone call about it after the submit the article that may make them want to update it. Updating articles may be a useful feature for your system, depending upon whether there is time to update if before editing/publication.

Josh

Anon

ok, now my head is really rolling on.. 🙂

but well, as its mentioned, the cookies carry the ID sign, and the data is actually saved on server side. jolly good! But what if the machine user is using has got cookies 'turned off' ? now that would be some problem.

i personally think, controlling everything on serverside is much better than relying on client side.

loading data twice might be bit slow, but these days every one i guess has 28K modems. And more specific to my case, our reporters use their own machines, or in some cases they can use from some caffe or whatever, and i think (i hope) none of the caffe has 300 baud 🙂

and about sending data to db over preview is fine, but as i mentioned before that what if reporter doesnt want to send after previewing? the record id increases and is then wasted.

we have user access level setup for all the reporters. few have high access level, who can submit the article, which goes straight to the website. but mostly the article goes to the pending on editor's list.

and yes, of course i have the editing too, incase the article is needed to be edited lateron.

thanks a lot to everyone who replied,
looks like the good old HIDDEN's are going to be fine (if we want FULL control on our system).

cheers,
Daarius ....

Anon

Be aware that if you use HIDDEN's that it is possible for someone to pull that page out of the cache, change some info, then re-submit it. If you use sessions, the session cookie expires when the browser is closed and there is no way to get to that data anymore unless they have physical access to the server.

Anon

i am using no-cache and expire = now, META tags in header.
and also, every single click that is made on my system, verifies from the db whether the user is logged in or not. if not then it raises an error. so ven after user logsout, if someone clicks back, and tries to click on any link, it will raise the error.

thanks, a lot
Daarius...

Anon

hi,
there is although a way not to use cookies at all 🙂 Try to make your phplib with ./configure flags --trans-sid --enable-track-vars. If you do so, php will attach the session id to every link. --> <a href=www.yourlink..domain> will look like this <a href=www.yourlink.domain?PHPSESSID=session_id>

sincerley Andreas

Anon

can someone give me a useful example source of using session and mysql for logins for users?
thanks alot :_

greenlantern

My host site is using PHP 4 with both --trans-sid --enable-track-vars. Nonetheless PHP does not automatically insert the session id on the URL when cookies are disabled. If I add it myself no problem but I do have to do it myself.