cookie/ID relationships

[ids]

g.Session_ID
s.callerid
s.http_cookie

I'm trying to figure out how to track a visitor through a session in MM. I am storing the Session_ID in a db. How should I check and see if the session already exists? Should I use s.callerid or g.sessionid.


<MvIF EXPR="{MyDB_Open()}">
<MvGO NAME="MyDB" ROW="top">
<MvFIND NAME="MyDB" VALUE="{g.Session_ID}" EXACT>
<MvIf EXPR="{NOT MyDB.d.EOF}">
<MvASSIGN NAME="g.IDS_Var" VALUE="{MyDB.d.var}">
</MvIF>
</MvIF>


If I display the value of these, I sometimes get 2 values for s.http_cookie. Is it possible that one machine, same store could get multiple values.

TIA
Scott

[Bruce - PhosphorMedia]

in case no one else who knows better answers, you can have multiple cookies for a site, hence multiple values...g.session_id will always be tied to what goes on in merchant, so if you are tracking merchant stuff, go with g.session_id.

[Tongo]

The few times i've dealt with cookies, i just stripped the htscallerid out of s.http_cookie and used that. It should be the same value as s.callerid but don't quote me on that.

OT: is it just me or is the forum loading super slow today? Took a whole 1:05 to load the reply page on cable modem.

[truXoft]

When client does not accept cookies, s.http_cookie will be blank and s.callerid will change with every new page, hence they are then worthless. At Miva Merchant, g.session_id should be persistent even in such situations, and should pass its value from one to another page through the URL or as a hidden form field. Though, if we speak about general Miva scripting (as the name of this sub-forum implicates), then no default g.session_id exists unless you create and maintain it - it is the developer of the given application that has to assure a session ID is being transferred from one page to another.

[ids]

I guess this is kind of an update and another related question.

My code works great to track the session when there is only one cookie/session_id. The problem is when there are two cookies for the same store on the same "client" computer. How can this actually happen?

Here's how I think it occurred. While in the store, a session_id/cookie has been established and is logged in my tracking db. I then entered the store seperately from a new browser window. The second ID is then tracked in the db.

Here's when I know the issue/problem is realized. When navigating from within the store, I use a hidden input to pass the required data from page to page. For instance moving from the storefront to product list screens, and back to the storefront, the prevailing session is, in my case, the second cookie. It will probably be the last one if there are more than two. The data displayed, is obviously from the other session. I need somehow decide/control which session data is displayed.

In writing this, I may have realized what I need to do. Do I also need to pass the session_id along with the data and compare? If coded properly, Would this allow one browser window to be independant, on the same machine? Any other thoughts about how this works or should/could work?

TIA

Scott

[ids]

When client does not accept cookies, s.http_cookie will be blank and s.callerid will change with every new page, hence they are then worthless. At Miva Merchant, g.session_id should be persistent even in such situations, and should pass its value from one to another page through the URL or as a hidden form field. Though, if we speak about general Miva scripting (as the name of this sub-forum implicates), then no default g.session_id exists unless you create and maintain it - it is the developer of the given application that has to assure a session ID is being transferred from one page to another.

Thanks IVO. I'm not currently dealing with the NON-ACCEPT cookie yet. But this info is still creates some answers. But another question: This is a Merchant session. Does the session_ID get passed from page to page indefinitely(well, the cookie lasts a year in default configuration)? What happens if another cookie is created on the same computer? What advice on how to control or decide on which session_id that is identified in the cookies?

TIA
Scott

[truXoft]

If client accepts cookies, g.session_ID is populated with the htscallerid stored in the cookie

[ids]

If client accepts cookies, g.session_ID is populated with the htscallerid stored in the cookie

Yes. I can see now when I display: s.http_cookie. But, here's this particular computers value (it really displays on a single line if your seeing 2 lines). So, which one is this session? Might it be s.callerid? Or, when would the last value get assigned to g.session_ID? I think that is where the problem i'm having is coming from.

htscallerid=e81e1dd3277cda5f7ca2768cabaa7017; htscallerid=1d32b573135c709793fc34500cba200b

Hope this explains my dilemma better.

Scott

[truXoft]

I don't remember, but either the first or (more likely) the last value is used. You can certainly verify it very quickly yourself, though :)

[ids]

I don't remember, but either the first or (more likely) the last value is used. You can certainly verify it very quickly yourself, though :)

Well, it looks like, so far, it's the last session_id in the cookie.

[truXoft]

Still, it is nonsense to use the cookie. Either use the g.session_id (if coding in Merchant) or the s.callerid - both contain the right value from the cookie (as long as cookies are accepted)

[ids]

Still, it is nonsense to use the cookie. Either use the g.session_id (if coding in Merchant) or the s.callerid - both contain the right value from the cookie (as long as cookies are accepted)

Of course it's non-sense when MM is creating the cookie, both cookies in fact. I never said I was using the cookie. I actually told, in my first post of this thread that I was using the g.session_ID to track the session, and I posted some code there.

Here is values that I am not creating: MM4(openui), just displaying in the storefront. The first set is a brand new browser window.

e81e1dd3277cda5f7ca2768cabaa7017
e81e1dd3277cda5f7ca2768cabaa7017
htscallerid=e81e1dd3277cda5f7ca2768cabaa7017; htscallerid=1d32b573135c709793fc34500cba200b

the first value is g.Session_ID
the second value is s.callerid
the third value is s.http_cookie

I understand the way MM works: MM searches for cookies on local machine. Creates if at least one doesn't exist. Populates the variable with the value of the htscallerid.

This next set of data, from within the same browser session. A form was used to change the value of the data I'm tracking through the session. For example of the data, literally, is TRACKVAR=1, was changed to TRACKVAR=3. The other operation taking place is SFNT to PLST then back to SFNT.

1d32b573135c709793fc34500cba200b
1d32b573135c709793fc34500cba200b
htscallerid=1d32b573135c709793fc34500cba200b

It isn't clear where or what the mechanism is that would pull the last value of htscallerid from the cookie. I have no code that even reads s.http_cookie. But g.session_ID is changed as a result of executing a form and/or changing from one screen to another and back.

So, if both htscallid values are in my tracking db, then the last one will be selected. NOT a desired result of course.

I'm thinking there must be something I can do make sure the session is using the initial g.session_ID.

[ids]

It appears the problem was in the form -- result of using or issuing a different htscallerid or a different session_ID.

Once I corrected the form...I'm getting the desired result.

Thanks everybody,

Scott

[Dramatic]

I guess this is kind of an update and another related question.

My code works great to track the session when there is only one cookie/session_id. The problem is when there are two cookies for the same store on the same "client" computer. How can this actually happen?

Cookies are not unique to the computer, they are unique to the browser. So the cookie I have in Opera is different from the cookie I have in Firefox and the cookie I have in IE. In fact I have two installations of Opera each with their own profile directory - the sessionids will be different for the same store.

Here's how I think it occurred. While in the store, a session_id/cookie has been established and is logged in my tracking db. I then entered the store seperately from a new browser window. The second ID is then tracked in the db.
Only if i) the second browser window is from a different browser, or ii) your entry point th second time was a secure page. In most cases secure pages have a different domain from insecure (you will occasionally see a secure cert set for www.domain).
e.g. If I go to a store for the first time in my browser, and stay on insecure pages, but then open a new window and type in the url of a secure page on the site, I will be entering the secure site without a cookie (the cookie has to be passed in a form or link when transitioning between http: and https: in either direction) so it will create a new cookie - giving me different id's in the same browser. If I take the original page to the secure section via a link, it will either pick up the cookie from the second window, or overwrite the cookie, depending on the script. Either way, one session will end up switching to the other's id and drop its basket.

[ids]

e.g. If I go to a store for the first time in my browser, and stay on insecure pages, but then open a new window and type in the url of a secure page on the site, I will be entering the secure site without a cookie (the cookie has to be passed in a form or link when transitioning between http: and https: in either direction) so it will create a new cookie - giving me different id's in the same browser. If I take the original page to the secure section via a link, it will either pick up the cookie from the second window, or overwrite the cookie, depending on the script. Either way, one session will end up switching to the other's id and drop its basket.

This is similar to what I concluded was the explaination. There were actually multiple forms. The path in one form was "http://www.domain.com." The rest were "http://domain.com." Changing the forms, that is combining the forms into one form solved the issue.