Best practices around "set-cookie"

[cpp-dev]

So I need to trigger a tweaked display based on incoming URL & UTM tag.

I know I can read the headers, so I've gotten that far.

My idea is to then set a semi-persistent cookie, so that while the specific incoming visitors get a similar header everywhere they go in the store.

I found this in the docs

<mvt:do file="g.module_library_utilities" name="g.null" value="SetCookie(g.Output_Cookies, g.cookie_name, g.cookie_value , g.cookiedomain , g.expires, g.cookiepath, 0 )" />

I've also been reading -- https://html.com/resources/cookies-ultimate-guide/

So, based on the example code, I'm not certain how to set the more broadly accepted 'good ideas' like "Secure" and "HTTPOnly".

Do I just set them?

like this:

<mvt:assign name="g.cookie_secure"   value="'Secure'" />

[ILoveHostasaurus]

If the site is all-https then you should definitely set those.

That being said, just something to keep in mind; serving of custom content to not-logged-in users can greatly limit scalability if the site in question is ever subject to, or expected to grow to, the point where it receives heavy bursts of traffic. Such a setup, along with the serving of cookies of any type to not-logged-in users, precludes the site from using caching at the web server or CDN level, along with the use of our own redis-based object cache that can be deployed as a module now, but will be a core feature in an upcoming release. These items can have a very significant effect on SEO given they can significantly reduce the TTFB for pages, often a minimum of 5x. There are of course many attractive reasons to want to customize content per shopper, so it's a trade off that must be weighed.

[cpp-dev]

Your point is well taken ILoveHostasaurus , thank you for the insights. This is meant to be a temporary measure, till we can come up with something better.

My initial thoughts are to maybe leverage the Transients feature to cache hold the changes so it's a much smaller change over all. Mostly what will happen is we'll display a new content section, but we need to make sure the visitor is coming from our partner's website.

[cpp-dev]

I have this on a 'dev' page, but when I run

var allCookies = document.cookie;
console.log(allCookies);
// here's the output
RESS_width=####; _uetsid=b90f131##########8c7c69; _uetvid=b90f5########3045f
undefined

I'm only seeing the cookies that are being set by the theme. Do the Miva cookies get stored some other way?

[dreamingdigital]

Javascript has no access to secure cookes created by Miva. For example combination facet cookies can not be set, removed or read by JavaScript. You have to use the Miva functions. (gave the example so you can sleuth).

How about using browser session storage? You can see the "continue shopping" link on newer Shadows for example of use.

[Bruce - PhosphorMedia]

Got one word for you son...Custom Basket Fields. Works just like a session cookie. Easier to use. No down sides. (unless you are using Deferred Baskets -- maybe.)

[cpp-dev]

Javascript has no access to secure cookes created by Miva. For example combination facet cookies can not be set, removed or read by JavaScript. You have to use the Miva functions.

Oh! Well that explains that. Thank you!

I'll give the code around the "continue shopping" a look.

[cpp-dev]

Got one word for you son...Custom Basket Fields. Works just like a session cookie. Easier to use. No down sides. (unless you are using Deferred Baskets -- maybe.)

Ok, that's very good to know. Back to the research mines I go.

And other than single page check out we're not doing anything else "fancy" with our basket.

[dreamingdigital]

Just be aware that high traffic sites saving custom basket fields will create a $0 basket for each visitor / bot. Hence why I think Miva is using session storage via JavaScript on the continue shopping link these days. ALSO if you are creating baskets for every customer by giving them custom basket fields then you won't have any benefits from turning on Redis page cache (as is now recommended by MM). So many options. :)