0

I have a site where people can create posts and submit them (like on Stackoverflow and Facebook).

One thing that the user can do is attach a photo before submitting the post. So as soon as the photo is attached (using AJAX), a new PostID is created in the backend database table for the post that's being worked on and stored in the user's SESSION scope e.g. SESSION.LoggedIn.PostID = rsInsertedPost.PostID.

The same things happens even if a photo isn't attached except that it will create the PostID on the final submission of the post instead.

The reason I store it in the SESSION scope is because the PostID that's just been created is used in multiple other areas in the backend application (CFC component in my case). For example, it will insert tags that the user associated with his post into a seperate table dbo.PostTags like such:

PostID | Tag
44       ColdFusion
44       Programming
44       SQL

After it has finished processing the form submission, it will remove the PostID from the user's SESSION.

The problem that I am about to encounter is when a user opens up multiple browser windows and decides to start working on multiple posts at the same time. The SESSION's PostID value will keep being overwritten by the newly created one which means that if they decided to go back to a different browser tab and submit their post it would end up affecting the last created Post.

What would be a good way to overcome this issue of keeping a track of PostIDs that people are currently working on per window. Is there some other unique attribute I could store in the SESSION alongside the PostID so that only that one will be affected per browser window thats open?

volume one
  • 6,800
  • 13
  • 67
  • 146
  • 4
    This is probably the number one argument against storing information in the session scope. The way to cope with it is to put the postId into a hidden form field or something similar and process it when you submit the form. – Dan Bracuk Aug 20 '16 at 12:59
  • @DanBracuk Is there no other alternative? I've tried looking in some books but I'm not sure under what 'topic' this would come. Could you suggest me some topics to look at that may deal with this type of scenario? – volume one Aug 20 '16 at 13:04
  • What is wrong with storing the id in a hidden field? – Leigh Aug 20 '16 at 16:18
  • @Leigh It can be manipulated by the user so I wanted to remove that risk out of the equation. I guess I probably can't avoid it? – volume one Aug 20 '16 at 16:34
  • 1
    Yes, that risk applies to any client side edits. Though I assume you also verify the current user id matches, not just record id? That said, nothing says you cannot use a structure, rather than a single value. The key could be a unique (throw-away) id that is passed backed to the client. For example, a uuid. When the form is submitted, look up the temp key and user id. If found, do the edit and remove it from the struct. Of course with either method, the data will disappear if the session times out.. – Leigh Aug 20 '16 at 16:47

1 Answers1

0

I like to use UUIDs. Then I'm sure to never use the same ID twice, not even across database tables. So instead of setting the PostID to a number (typically 1 + the last id in the database table), use #createUUID()#.

Jules
  • 1,941
  • 15
  • 18