Announcement

Collapse
No announcement yet.

s.callerid is gone?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    s.callerid is gone?

    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?
    M.A.D.* since 1997

    http://www.scotsscripts.com

    *miva application developers

    #2
    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.
    David Hubbard
    CIO
    Miva
    [email protected]
    http://www.miva.com

    Comment


      #3
      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?
      M.A.D.* since 1997

      http://www.scotsscripts.com

      *miva application developers

      Comment


        #4
        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.
        David Hubbard
        CIO
        Miva
        [email protected]
        http://www.miva.com

        Comment


          #5
          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.
          M.A.D.* since 1997

          http://www.scotsscripts.com

          *miva application developers

          Comment


            #6
            I think I missed something. When was 5.44 released? Did a notice go out?
            William Gilligan - Orange Marmalade, Inc.
            www.OrangeMarmaladeinc.com

            Comment


              #7
              Empresa 5.34 was released prior to Miva Merchant version 10.
              David Hubbard
              CIO
              Miva
              [email protected]
              http://www.miva.com

              Comment


                #8
                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

                What help do you need today!
                Interactive Design Solutions http://www.southbound.com
                MivaMerchant Business Partner | Certified MivaMerchant Web Developer
                My T-shirt Collection is mostly MivaCon T-shirts!!
                Competitive Rates, Popular Modules, and Integrations:
                Product Copy | AutoBaskets | Waitlist Integration| Wholesale Integration

                Comment


                  #9
                  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.
                  David Hubbard
                  CIO
                  Miva
                  [email protected]
                  http://www.miva.com

                  Comment


                    #10
                    Is there a reliable one I could use instead?

                    SCott
                    What help do you need today!
                    Interactive Design Solutions http://www.southbound.com
                    MivaMerchant Business Partner | Certified MivaMerchant Web Developer
                    My T-shirt Collection is mostly MivaCon T-shirts!!
                    Competitive Rates, Popular Modules, and Integrations:
                    Product Copy | AutoBaskets | Waitlist Integration| Wholesale Integration

                    Comment


                      #11
                      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.
                      David Hubbard
                      CIO
                      Miva
                      [email protected]
                      http://www.miva.com

                      Comment


                        #12
                        Will mivascript.com be updated with these changes? Just checked and the info on the callerid is still there - which could mess up developers.
                        William Gilligan - Orange Marmalade, Inc.
                        www.OrangeMarmaladeinc.com

                        Comment


                          #13
                          I've asked that it be updated.
                          David Hubbard
                          CIO
                          Miva
                          [email protected]
                          http://www.miva.com

                          Comment


                            #14
                            ATM, mivascript.com can't be reached... in Silicon Valley?
                            What help do you need today!
                            Interactive Design Solutions http://www.southbound.com
                            MivaMerchant Business Partner | Certified MivaMerchant Web Developer
                            My T-shirt Collection is mostly MivaCon T-shirts!!
                            Competitive Rates, Popular Modules, and Integrations:
                            Product Copy | AutoBaskets | Waitlist Integration| Wholesale Integration

                            Comment


                              #15
                              I tested from a few random down detectors; all were able to reach it.
                              David Hubbard
                              CIO
                              Miva
                              [email protected]
                              http://www.miva.com

                              Comment

                              Working...
                              X