s.callerid is gone?

[Scot - ScotsScripts.com]

My host updated to empressa 5.34 and all of a sudden there is no s.callerid which has broken my standalone scripts that rely on it to handle user sessions.

Worse yet since I never coded anything to see if s.callerid would not have a value (since it has always had a value kind of the same way that we always have gravity) I had some major hack attacks on a couple non-miva merchant sites and was simply lucky to catch them as they were happening.

What is the deal with this and how can I get around it?

I notice the htscallerid cookie is still there so my current fix is to check to see if s.callerid is empty then read the cookie instead, but I have no idea if that's a reliable way to do this. Is it? Or is it not?

Where are the release notes for 5.34? I probably need to know if anything else has been removed that I'm using.

Please remember that people use miva script in environments where there is no miva merchant. It is my go-to scripting language for custom sites and web apps. Removing an integral system variable without a public warning was an oversight and could affect all sorts of downline stuff that has been built using miva script.

When you guys updated to mm5 there was a list of items that needed to be addressed for modules and scripts to work properly, is there a document like this anywhere for mm10/5.34?

[ILoveHostasaurus]

You can manually re-enable it if you're relying on Empresa to handle sessions; it would be usecookies=1 in the mivavm.conf file or MvCONFIG_COOKIES 1 in environment variable config. This change is covered in the release notes and readme files included with the Empresa downloads at https://www.miva.com/support/downloads

If you are still sending an htscallerid cookie but have that feature disabled server side, it will not have an effect or cause that variable to be defined until re-enabled.

This was turned off for a variety of reasons, including both security and performance. Having it on will create an issue of having the same cookie be used for both insecure and secure sessions, given Empresa does not differentiate. This can cause issues for businesses desiring to operate in a manner consistent with various regulatory/industry standards (such as PCI), will often cause security scans to fail, could result in unencrypted access to content intended to be secure for custom apps other than Miva Merchant, etc. On the performance side, the serving of a cookie with a response will cause most caching CDN's to not cache, meaning any site with htscallerid being set cannot be cached by Cloudflare and similar, even for requests entirely compatible with caching (such as JS resources from clientside.mvc, content for not logged in shoppers, etc.).

If the site in question is hosted with us, you can request that we blacklist it from receiving Empresa upgrades, as our software delivery architecture is geared specifically for Miva Merchant usage. If a historical Empresa default creates issues for Miva Merchant stores as the software changes, it would not be possible to preserve such a default. For non-Merchant MivaScript apps that need testing on new versions before deployment to production environments, blacklisting would be the recommendation.

[Scot - ScotsScripts.com]

I got around it by creating my own session cookie, probably should have done that years ago.

What do you mean by:

"On the performance side, the serving of a cookie with a response will cause most caching CDN's to not cache, meaning any site with htscallerid being set cannot be cached by Cloudflare and similar, even for requests entirely compatible with caching..."

Are you saying we shouldn't be using cookies to track sessions?

[ILoveHostasaurus]

No, the issue is that if a cookie is not otherwise needed, serving one will result in decreased performance, possibly significantly if a CDN is in play, or the shopper is behind an ISP or corporate caching proxy/firewall. With Empresa serving htscallerid blindly, whether needed or not, such a degradation could occur. Merchant on the other hand, handling its own sessions, only actually begins sending cookies when needed. So, for example, a non-logged-in shopper, on a site where nothing in the page needs to be specific to them, should not receive a cookie. Once they log in, or if the application in question needs to track them for other reasons (unique content, analytics, etc), then that is ideally when cookies would start going out.

[Scot - ScotsScripts.com]

Cool, thanks for that, it's kind of what I thought. My new session system sets tracking cookies after someone logs in and removes them when they log out or have gone past the inactivity timer so I think I'm good there.

[wmgilligan]

I think I missed something. When was 5.44 released? Did a notice go out?

[ILoveHostasaurus]

Empresa 5.34 was released prior to Miva Merchant version 10.

[ids]

David,

I was using s.callerid in a module. It was a consistent value I could count on. Could g.session:browser_id be used as a replacement?

Scott

[ILoveHostasaurus]

That's the cookie resulting from a Miva Merchant browser validation process; I would not rely on that for other apps to use as a session cookie on the same domain.

[ids]

Is there a reliable one I could use instead?

SCott

[ILoveHostasaurus]

There are only two choices; have Empresa set a session cookie for you indiscriminately with every request, and then you may have both security and performance issues since it would be every request whether needed or not, and with on control over any flags being set on those cookies, or have your application set and manage its own session cookies. If your application manages its own sessions, it should be 100% reliable.

[wmgilligan]

Will mivascript.com be updated with these changes? Just checked and the info on the callerid is still there - which could mess up developers.

[ILoveHostasaurus]

I've asked that it be updated.

[ids]

ATM, mivascript.com can't be reached... in Silicon Valley?

[ILoveHostasaurus]

I tested from a few random down detectors; all were able to reach it.