cp.utag_main_v_id... cookie gets set to undefined

[ayuan]

Recently we implemented a Tealium integration into our local environments which has worked well with Tealium tools but has started creating a very large cookie which eventually gets set to undefined.

Specifically we run our local environments on localhost:PORT so I imagine perhaps on our local environments, Tealium might be looking for something that it cannot find. I have verified that on our testing and production environments this does not happen but would like to find a good fix for this if possible so that we do not have to have our devs clear their cookies once this gets really large.

If I can provide anymore information, feel free to let me know. I have also read https://community.tealiumiq.com/t5/Tealium-iQ-Tag-Management/Tealium-Cookies/ta-p/138 regarding cookies but did not find any good advice regarding this.

[dan_george]

@ayuan Typically trying to run Tealium on a localhost domain isn't suggested. Some vendors, like Google Universal Analytics, won't even set a cookie on this domain since it doesn't follow the standard domain format and therefore their tag cannot be triggered. Not that it should affect Tealium, just a suggestion.

That being said, I find it odd that the whole contents of the utag_main cookie namespace are being jammed into that cooke parameter. Are you able to state the device(s), app(s) or browser(s) being used, and the steps you are taking where this is happening?

Lastly, this is a bit of a unique issue where it may require contacting your Deployment Manager so that they can loop in a technical resource. If you have a sample HTML page or two that you can provide your DM so we can replicate that would be helpful.

Cheers,

-Dan George

[ayuan]

No that makes sense -- to clarify we don't expect data to come through this. We use Tealium tools locally to verify with the test recorder that events are "triggering" although they may not go anywhere and this is also how we did it with GA with the GA Debugger extension (this way devs can test their events are "working" before we ask QA teams to verify).

The browser we are testing this on is Chrome 56 latest and this happens on load. The first session works fine when the cookie has been cleared but, upon further sessions, the undefined case becomes apparent and the cookie starts to grow.

[Mauricio]

I think you may have a malformed URI. The values in the data layer look like what happens when utag.js is unable to perform a decodeURIComponent on your URL. All the values of the data are wrong. Your hash is actually your querystring, your domain has no port value.

From the devtools try:

decodeURIComponent(document.URL)

What happens?

[ayuan]

@Mauricio, when I run 

decodeURIComponent(document.URL)

it returns

http://localhost:3000/

We do have some cases "malformed" urls such as this one. If this is the issue, we can probably look into a fix for this.

http://localhost:3000/#?b=9f1352aa-45aa-4c6f-ac56-7618d3521442&n=d60b4933-7b87-4977-953d-64464e4da791&

I don't think that's the issue though -- I tested multiple times without using the "malformed" url ( so using localhost:3000 ) and I get the same cookie malfunction upon reload. So when I go to localhost:3000, confirm that decodeURIComponent(document.URL) returns http://localhost:3000/ and then an immediate refresh, my cookie becomes this:

[steve_lake]

Hi @ayuan, 

I think this is a restriction that can be turned on within Chrome's security settings (cookie.secure = true, if I remember correctly)  

Can you try using https://127.0.0.1:3000/ instead? 

Alternatively, try setting up a fictional domain name in your operating system's host file for localhost.  In OSX or Linux this is located in /etc/hosts, in Windows it is in c:\Windows\System32\Drivers\etc\hosts 

For example: 

# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##

127.0.0.1 localhost
127.0.0.1 mylocaltestdomain.com

[ayuan]

@steve_lake I just tested this and unfortunately the issue still persists. We also use localhost for another one of our services on a different port that requires secure cookies so I do not think this is the issue. Our /etc/hosts file does have localhost as a registered domain and I have also tried going to 

chrome://flags/#allow-insecure-localhost

in Chrome and enabling that but I still see the issue :/ 

[steve_lake]

Ok, thanks for your reply. 

It's probably worth raising a support ticket so that we can look at your account and profile and determine what is happening. 

Thanks

Steve Lake

[Mauricio · Accepted solution]

Hi @ayuan,

Indeed you do have a malformed URL but like you said this might not be the cause. Let me ask is this a single page application that uses React or Angular?

I've seen this issue before when the page is loading too fast. For testing purposes you can create a JS Code extension scoped to PreLoader with the code below. Make sure this extension is at the top of your TIQ extensions tab. (the first extension).

// utag.js config override
(function(global) {
    global.utag_cfg_ovrd = global.utag_cfg_ovrd || {};
    global.utag_cfg_ovrd.dom_complete = true;
})(window)

 Kindof a longshot but might be worth giving it a shot. I also have a testing environment being served from localhost and I do not have this issue like you do.

Below I'm pasting a slightly modified version of the utag.js readcookie function that you can also just paste into the devtools. Set a breakpoint on the first line of utag.js, execute the code below and then call `read_cookies()`. Do your cookies come back malformed at this point? No cookies yet? What about if you call `read_cookies` after utag.js runs?

/**
 *  mod version of utag.loader.RC
 *  ex: read_cookies() or read_cookies('utag_main')
 *  @param   {string}  name  :optional name of cookie. will read all cookies if no name is passed in.
 *  @return  {object}        :returns parsed cookies
 */
var read_cookies = function(cookie) {
  for (var t, cookie_key, cookie_val, obj = {}, cookies = "" + document.cookie != "" ? document.cookie.split("; ") : [], white_space = /^(.*?)=(.*)$/, exp = /^(.*);exp-(.*)$/, date = (new Date).getTime(), f = 0; f < cookies.length; f++) {
    cookies[f].match(white_space) && (cookie_key = RegExp.$1, cookie_val = RegExp.$2);
    var decoded = decodeURIComponent(cookie_val);
    if ("undefined" != typeof cookie_key)
      if (0 == cookie_key.indexOf("ulog") || 0 == cookie_key.indexOf("utag_")) {
        decoded = cookie_val.split("$"), match = [], params = {};
        for (var k = 0; k < decoded.length; k++) {
          if (match = decoded[k].split(":"), match.length > 2 && (match[1] = match.slice(1).join(":")), size = "", 0 == ("" + match[1]).indexOf("~")) {
            for (segments = match[1].substring(1).split("|"), j = 0; j < segments.length; j++) segments[j] = decodeURIComponent(segments[j]);
            size = segments
          } else size = decodeURIComponent(match[1]);
          params[match[0]] = size
        }
        obj[cookie_key] = {};
        for (var key in params) {
          if (Array.isArray(params[key])) {
            markers = [];
            for (var h = 0; h < params[key].length; h++) params[key][h].match(exp) && (t = "session" === RegExp.$2 ? "undefined" != typeof params._st ? params._st : date - 1 : parseInt(RegExp.$2), t > date && (markers[h] = 0 == $1 ? params[key][h] : RegExp.$1));
            params[key] = markers.join("|")
          } else params[key] = "" + params[key], params[key].match(exp) && (t = "session" == RegExp.$2 ? "undefined" != typeof params._st ? params._st : date - 1 : parseInt(RegExp.$2), params[key] = t < date ? null : 0 == $1 ? params[key] : RegExp.$1);
          params[key] && (obj[cookie_key][key] = params[key])
        }
      } else obj[cookie_key] = decoded
  }
  return cookie ? obj[cookie] ? obj[cookie] : {} : obj
}

What I'm thinking is that you have a character in your cookies that is throwing off how utag.js is parsing(obvious I know). But one bad key in a cookie can throw off the entire function (since it loops through the keys in document.cookies and parsing mistakes will compound).

[ayuan]

Hey @Mauricio sorry for the late reply. I know it's been a few months but I tried the things you mentioned and unfortunately we still see the issue. We are using a React application but I cannot confirm if this is because the application is loading too fast.

It's interesting because accessing the window.utag, it looks like everything is fine but the v_id and everything subsequent to it doesn't get decoded and remains encoded.

I did the read_cookies and yes the utag_main still comes back malformed :(

EDIT: Hey @Mauricio apologies! Actually I started stepping through the utag.js file and did see that the cookie isn't malformed in the beginning but it does later get malformed. I'm gonna look a little more into it. Thanks a lot for that advice!

[Mauricio]

PMing you directly so we can set up a time to screenshare.

[ayuan]

Hey so we figured out the issue. Big props to @Mauricio for helping me through this. We stepped through utag.js and found that it was setting things correctly and something in our express development server for webpack that was changing the cookie and malforming it. Thank you so much! I'll reopen this if there are more issues!

[kathleen_jo]

Thank you for coming back to TLC and letting us know @ayuan! It's always great to hear when an issue gets resolved. 

You ROCK @Mauricio! Thank you, Sir!