_satellite.isSubdomainOf produces false positives and affects _satellite.isOutboundLink

[aseelund]

we are considering weareyardhouse.com an outbound link and this is a separate property in regards to our brand sites for www.yardhouse.com or m.yardhouse.com

Line 3278 provides an incorrect result.

You can see the incorrect value by directly running the following in the browser: This should return false, however it returns true;

_satellite.isSubdomainOf('www.weareyardhouse.com','yardhouse.com');

This is a corrected implementation of isSubdomainOf() --- something we have staged for testing

_satellite.isSubdomainOf = function(e,t){ if(e===t){return !0};var f=e.split('.');var eStr=[f[f.length-2],f[f.length-1]].join('.'); console.log(eStr); if(eStr === t){return !0}else{return !1}}

Given the domain “test1adobe.com” and “adobe.com”, do they have the same base domain? Is the test string a subdomain of adobe.com or are these two unique domains?

We feel that this is a bug and the method is producing false positives, can anyone else reproduce on their own domains, or have noted issues with isOutboundLink not working as expected?

Incoming test Value

Matching on unique domains

Test Values

Test case:

_satellite.isSubdomainOf('www.test1adobe.com','adobe.com');

// should return false, instead returns true.

Test case 2:

_satellite.isSubdomainOf('www.test1.adobe.com','adobe.com');

// returns true. Please note dot placement.

In fact, open console in your web browser, even here in the forums and run the above code.

[josh_donley]

The official answer to all this is _satellite.isSubdomainOf and _satellite.isOutboundLink are not public facing methods, therefore you should not be using them.

That aside.. I'm not necessarily saying I disagree with your assessment, but I'd like to better understand why you think this is an actual bug? Do you have official internal documentation for them, or are you making assumptions based on the naming conventions? Seems to me that without documentation for intended behavior, we could equally assume they are working as intended and someone is terrible at naming conventions!

[aseelund]

Thanks joshd7227840​, we are only using isOutboundLink in the rule, as it was used in the original design of our solution. We have actually taken the step to override isSubdomainOf and provide corrected functionality so that isOutboundLink works as expected.

As a developer, I consider a function that doesn't provide expected results a bug. Therefore, isSubdomainOf relays the message that it checks to see if a given test case "is a subdomain of" a sample. It doesn't, so we fixed it. Documentation aside, the naming should have been "fooBar" if it wasn't going to return the expected results of what its named to do, but semantics.

We'll code around it, not much else we can do officially. I hope the replacement method helps others if they are falling into similar cases.

Corrected IsSubdomainOf (we placed this after doPlugins). This essentially splits at domains periods and then re-joins the last two values of the array to determine if the root domain matches.

_satellite.isSubdomainOf = function(e,t){ if(e===t){return !0};var f=e.split('.');var eStr=[f[f.length-2],f[f.length-1]].join('.'); _satellite.notify(eStr); if(eStr === t){return !0}else{return !1}}

[aseelund]

And for what its worth, there is Official docu from the omniture.com site, in regards to DTM for both of these methods, as described.

http://microsite.omniture.com/t2/help/en_US/dtm/object_reference.pdf

See Pages 21 and 23

[jantzen_b]

That appears to be draft documentation from 2013. I'll have our doc writer take a look and pull that down if it's no longer valid. The correct object reference is the one I linked above.

[josh_donley]

I certainly +1 your efforts to create a function that does what you want it to, and I hope it will be of use to others as something to use under their own namespace.

I agree that a function that doesn't provide expected results is a bug, but I have yet to see proof that this is an actual bug. And even if it were a bug,  I cannot agree with you overwriting DTM's function like this, nor can I agree with you using these internal functions to begin with, even if they were to function exactly as you want them to.

It certainly isn't functioning the way you want it to function, no question about that. But you aren't the author or maintainer of this function, nor do you have documentation explaining intended behavior. Without documentation detailing expected results, you cannot make assumptions about how it should be expected to function.

Also, it seems pretty risky to me overwriting an internal DTM function to behave the way you want it to behave. Have you done a thorough audit of where that function is used elsewhere, and how it impacts that?  Are you going to keep track of all changes to the core DTM library to make sure nothing was added or changed that relies on these internal functions working the way they do now, vs. what you've changed it to?

Of course there's something else you can officially do: if DTM's functionality is failing you, then don't use it.

write your own code in its own namespace and use that, instead.

All that aside.. as I previously mentioned, I actually don't necessarily disagree with this being a bug. In fact, I personally would vote on calling this a bug. We're actually on the same page on that count.  I simply disagree with outright calling it a bug without documentation of intended behavior (or an official response from Adobe about it), and I disagree with how you are responding to / overcoming it. 

Have you submitted a ticket to Adobe to investigate?

[aseelund]

Yes, we have already gone through internal Adobe processes with clientcare and engineering and the only resolution was to post here in the forums and "its working as intended".

[josh_donley]

"its working as intended"

If I had a nickel for every time I've heard that from Adobe Engineering, even for things that are quite obviously bugs (official documentation does NOT match behavior) ...

[jantzen_b]

I second Josh's answer. Using any object reference that is not listed in the documentation is risky and unsupported. All object references outside of the approved list are subject to change at any point without notice. Also, any migration or automated tools built by Adobe, will not be built to accommodate these references.