Is it possible to maintain a cookie (containing a unique session ID relating to server-side session details) for a browser window?

Example:

Let's say I have:

home
home/profile
home/search_products
home/browse_products
home/{product_page}

And, let's say I want to display a history of the visitor's last 10 activities. If they open two browsers (maybe browsing two different product families simultaneously), is it possible to differentiate those two browsers as different "sessions" (so their browsing history can be displayed accurately to each browser window)?

I've thought about using a path containing a parm like "/cgi-bin/script_name/unique_parm". I think the "unique parm" would be treated by the browser's cookie capabilities as part of a unique path to associate a cookie too.

But, I'm not sure how reliable that is. For example, if the user right-clicks on a link and says "open in new window" it may appear they followed the link from the existing "unique_parm" path (existing session).

I feel like I'm overcomplicating this. Before spending more brain cells on it, I thought I'd ask if there's a more straightforward way to differentiate between two browser sessions (on the same computer).

Thanks,
Mark

Another idea might be to add the "activities" to hidden form fields (or to the URL query string) each time a form is submitted.

Thanks. That would work until they navigate away from a POST page. Maybe the "contact us" page, then back to searching/browsing products.

It's a perplexing challenge. Maybe it's not something which HTTP was intended to accomplish.

I've been thinking of adding a "parm" to the path, so that it looks like



I believe the cookie would be scoped to that path. No other browser instance surfing the same site would serve the cookie scoped to that unique path.

So, then the challenge is to detect when

1. A visitor arrives without the "/unique_session_id" part of the path,
- Create that value, give them a cookie to match them as the active user of that unique path (so, if they email a link to someone else, and they visit without the cookie, they can be treated differently). Redirect to the unique path.
- All URLs (navigation links, POST targets, etc.) will be dynamically created with the "/unique_session_id" so that all traffic will easily correlate to the unique browser instance.

2. A visitor arrives with the unique path, but no cookie.
- Maybe they received the URL in an email. Or, it's a bookmarked link. They closed and reopened their browser.
- Treat it like #1. (Start over with new unique path value.).

3. A visitor with unique path, and the cookie for that path. But, the referrer_url indicates they didn't come from a page with the unique path.
- Visitor pasted a URL into a new browser window?
- Treat it like #1. (Start over with new unique path value.).

That sounds workable. But, I'm thinking there are things which will break it. Example: visitor right clicks a link and "open link in new window." Will that always have a blank referrer_url? If not, my idea breaks. Two browser instances will share the same cookie scoped to the same unique URL.

To me, it's interesting. But, something tells me it's a futile attempt to do something beyond what is possible.

Mark

If I understand you correctly, you want separate cookie information for separate sessions? But why bother: you have to identify the separate sessions _somehow_ (doesn't matter whether you add ?session=12345 or a fake directory as /session12345). Once you have identified the session, you may as well hold all the information in your database to simplify things. Or if you are concerned about storage space, and want to be able to leave the info on the client computer indefinitely, simply save cookie variables such as name12345=Fred Bloggs tel12345=01234567.

Remember also that you may be able to provide separate sessions simultaneously, but unless there is a powerful reason to do so, you may just end up confusing the user.

That depends on how they open the "two browsers". If they use shift-click to open a link in a new window/tab, then the only thing I can think of would be to use JavaScript on the new page to detect that there is no history in that window. Viewing the history would be a security hole, but there might be a way to detect whether the history exists without actually viewing it. The usual disclaimers about the unreliability of client-side scripting apply...

Personally, I don't want sites to worry about such things. I open new tabs all the time when shopping. The web sites shouldn't care about that, and it's fine with me if my "recently viewed items" shows everything I've viewed in all the tabs I have open at that site.

Thanks, you're probably right. In my case it shouldn't be a problem if concurrent browsing sessions (of one user) display (in all sessions) the cummulative products viewed by all sessions.

However, isn't there a legitimate need for this kind of session uniqueness? A site where sequence of action is important? A game? Working through levels of a problem that can be approached in a variety of ways?

I understand that if the sequence is written as forms, the sequence-sensitive info could be saved as a hidden field. But, that opens up other problems like the visitor messing with their hidden fields. Saving the form, executing it later.

Maybe the way to do this is using a second unique value on all the links in the page (in addition to the unique value added as part of the path, to give unique scope to the cookie for that browser window). You save (in the server-side session) the unique value associated with all the links that can be clicked, and invalidate that unique value when they click a link (returning to the server with a URL containing that unique value). This way, if they shift-click (open in new window) or paste the URL into another window, it would be treated as *the* unique response from the page containing that link. It (or subsequent attempts) would fail because the server-side unique link-value would have been discarded the first time any link from that page was completed (resulting in a new page, with a new server-side unique link-value awaiting one new activity to invalidate that new value).

It's an interesting thought experiment.

Mark