Issue With Miva Merchant Cookies - Please Verify

[Bruce - PhosphorMedia]

Re: Issue With Miva Merchant Cookies - Please Verify

We use basket:cust_id to determine if the customer is logged in or not (and also do a check to see if billing email address is already used as an account name, since they could have an account and NOT be logged in).

And yes, after creating the account, we log them in and take them to the ACED screen in case they want to change any of the information. For example, they where ordering a gift shipped to a different address and want to change it back to their billing address.

[Brandon MUS]

Re: Issue With Miva Merchant Cookies - Please Verify

Bruce, have you verified that your implementation still works post-PR7? If so, I would be very curious to hear (perhaps via PM if it's sensitive) what you're doing that I am not. We're trying to accomplish exactly what you described.

[Bruce - PhosphorMedia]

Re: Issue With Miva Merchant Cookies - Please Verify

Bruce, have you verified that your implementation still works post-PR7? If so, I would be very curious to hear (perhaps via PM if it's sensitive) what you're doing that I am not. We're trying to accomplish exactly what you described.

Yes, it works post/pre PR7.

[Brandon MUS]

Re: Issue With Miva Merchant Cookies - Please Verify

Any idea what you're doing differently by chance? Are you just submitting directly to ACED from INVC?

[alphabet]

Re: Issue With Miva Merchant Cookies - Please Verify

There are several ways to solve this issue. For most, PM Easy Account is by far the easiest implementation and well worth the investment considering the time to create and maintain alternate solutions.

I created a PRE_ACTION to reset the sessionid with toolbelt.

1. Create new page PREACTION_ICST

<mvt:comment>PREACTION_ICST</mvt:comment>
<mvt:if expr="(ISNULL g.PreAction) AND ('PREACTION_' IN g.Action NE 1)">
  <mvt:exit />
</mvt:if>
<mvt:item name="ry_toolbelt" param="do|g.module_library_utilities|g.Session_ID|DetermineSessionID()" />

2. Add hidden input to form:

<input type="hidden" name="Store_Code" value="&mvte:global:Store_Code;">
<input type="hidden" name="PreAction" value="PREACTION_ICST">
<input type="hidden" name="Action" value="ICST">
<input type="hidden" name="Screen" value="ACED">
<input type="hidden" name="PrevPage" value="INVC">

I tested it a few times and it would create a new account and send user to ACED. I use PrevPage variable on ACED to test condition to update orders table cust_id field.

[Bruce - PhosphorMedia]

Re: Issue With Miva Merchant Cookies - Please Verify

Any idea what you're doing differently by chance? Are you just submitting directly to ACED from INVC?

Since I haven't reviewed your script in detail, my assumption is that EasyAccount does most of its work "internally" meaning the session cookie functions don't even see what we are doing, and when we start, we are simply under the secure checkout cookie.

We then log the user back in using their account info. I honestly never checked to see if we create a new cookie or not since no issue ever came up around this.

[Brandon MUS]

Re: Issue With Miva Merchant Cookies - Please Verify

Brennan or Rick, can you ping Burch on this if he is back?

[Rick Wilson]

Re: Issue With Miva Merchant Cookies - Please Verify

He got back today, I'll ask him to look at it.

[burch]

Re: Issue With Miva Merchant Cookies - Please Verify

I'm able to recreate the out of date cookie behavior but not the failure to login.

When a customer is not logged in at checkout, we delete the basket record but leave the basket cookie in place. I suppose this could be considered a bug, but in practice (at least in my experiments here) it doesn't cause any problems because we update the cookie when a new basket record is created on the next page hit. The same scenario could happen if the basket expires on the server side prior to the cookie expiring. This behavior also did not change between PR6 and PR7--we've never explicitly expired the basket cookie on checkout, and have always deleted the basket record.

I set up a simple test with a form on the INVC page that uses the ICST action to create a customer account. In all of my testing, the customer account is properly created and the basket cookie is updated, leaving the customer logged in and ready to go. You should be able to see it yourself at:

http://dev.coolcommerce.net/mm5/merchant.mvc

There's a single free product in that store and the form on the INVC page allows you to choose the destination page. I've tried SFNT and ACLN without issues.

My solution does not have a redirect, which leads me to believe that is the real cause of the issue. I wonder if the browser is treating one of our cookies as a third-party cookie for some reason and refusing to send it on the redirect. Some things you might want to check:

1. Does your site output a P3P header?
2. Do the URLs used to load the SFNT and DASH pages use exactly the same domain name?
3. Have you modified the Miva Merchant cookie settings (domain and path) in any way?

[Brandon MUS]

Re: Issue With Miva Merchant Cookies - Please Verify

Thanks for looking in to this Burch. I'm sure you have a pile of work you'd rather be doing.

I wasn't able to get to dev.coolcommerce.net to test on your site. Do you have it locked down maybe? Happy to add a record to my hosts file if I need to.

One angle I would like to have you try is if a basket cookie is recreated on a HTTPS page. During checkout and when creating a new account, the customer never leaves the security of https, and I think that may be causing the issue (see earlier in the thread where Rick and I talked briefly about this).

1. Yes. CP="NOI DEVa TAIa OUR BUS UNI STA"
2. Yes, all are on https://www.MYDOMAIN.com. All of the links are simply /merchant.mvc?Screen=XXXX
3. I know my path is typical, but I can't remember if the default settings had the leading period in the domain or not. My cookie settings are as follows:

Non-secure URL to Miva Merchant: http://www.MYDOMAIN.com/mm5/merchant.mvc?
Non-secure Miva Merchant Cookie "domain": .www.MYDOMAIN.com
Non-secure Miva Merchant Cookie "path": /
Secure URL to Miva Merchant: https://www.MYDOMAIN.com/mm5/merchant.mvc?
Secure Miva Merchant Cookie "domain": .www.MYDOMAIN.com
Secure Miva Merchant Cookie "path": /

[burch]

Re: Issue With Miva Merchant Cookies - Please Verify

I wasn't able to get to dev.coolcommerce.net to test on your site. Do you have it locked down maybe? Happy to add a record to my hosts file if I need to.

Sorry, I forgot to open the hole in our firewall. It should be working now if you want to try it. I'll leave the firewall open for a couple of hours at least.

One angle I would like to have you try is if a basket cookie is recreated on a HTTPS page. During checkout and when creating a new account, the customer never leaves the security of https, and I think that may be causing the issue (see earlier in the thread where Rick and I talked briefly about this).

I think you are right. If, after creating the account, I just go directly to the storefront page by retyping the URL, I'm not logged in. I think the only thing saving me is that the secure url's always include the Session_ID parameter and I have the store configured to include it when transitioning between secure and non-secure (the default setting).

Your workaround is probably OK with the PCI scanners because they're not intelligent enough to get to the INVC page in the first place (and from a real security standpoint there's no issue with what you're doing anyway). A solution without toolkit would probably require a non-secure intermediate page and steps something like this:

1. Land on SFNT (or any other secure page), create the customer
2. Redirect to non-secure page with a URL including Session_ID
3. Redirect to the secure DASH page

1. Yes. CP="NOI DEVa TAIa OUR BUS UNI STA"
2. Yes, all are on https://www.MYDOMAIN.com. All of the links are simply /merchant.mvc?Screen=XXXX
3. I know my path is typical, but I can't remember if the default settings had the leading period in the domain or not. My cookie settings are as follows:

Non-secure URL to Miva Merchant: http://www.MYDOMAIN.com/mm5/merchant.mvc?
Non-secure Miva Merchant Cookie "domain": .www.MYDOMAIN.com
Non-secure Miva Merchant Cookie "path": /
Secure URL to Miva Merchant: https://www.MYDOMAIN.com/mm5/merchant.mvc?
Secure Miva Merchant Cookie "domain": .www.MYDOMAIN.com
Secure Miva Merchant Cookie "path": /

These all look fine

[Bruce - PhosphorMedia]

Re: Issue With Miva Merchant Cookies - Please Verify

Brandon,

But wouldn't all of this be moot if you don't use the Basket_Session cookie? I don't quite understand what value that brings. Basket:cust_id is quite adequate for determining if the shopper is logged in or not. And, if you are using BillTo email as login (like we are) a simple lookup in the orders table will determine if they already have a login. (This test can also be extended to include previous orders, but you would want to ASK the shopper first.) Alternately, you can query the Customer Database for matching password email, shipping or billing email. Again, if this is found, you'd probably want to change the message to specifically ask permission. There may be a reason they DIDN'T want to log in.

[Brandon MUS]

Re: Issue With Miva Merchant Cookies - Please Verify

Tested it on your site and I think you're right about the session variable in the url. If I watch my cookie value, the basket-id value doesn't change until I click on a link starting with http://. If the link contains the session id as a variable, nothing is lost, but if it doesn't, I start anew.

You don't even have to place a test order to see this happen really.
Delete your cookies.
Go to https LOGN (without clicking a link).
Note the Session_ID in all of the links, yet you have no basket-id cookie yet.
Log in to your account.
You are on https ACLN, and appear to be logged in.
Go to http SFNT (without clicking a link).
Your basket-id cookie has been created, but you are not logged in anymore because the cookie value doesn't match your old session_id.

I see this as an issue since many store owners don't want to use the session id variable in the urls.

[burch]

Re: Issue With Miva Merchant Cookies - Please Verify

I see this as an issue since many store owners don't want to use the session id variable in the urls.

I completely agree, but more than one PCI scanner will flag any attempt to set the same cookie on both HTTP and HTTPS URLs as a high-priority vulnerability. The issue comes up whenever a shopper lands on the site for the first time on an HTTPS URL.

For people that have sensible PCI scanners or want to run their entire site over HTTPS it may be worth adding a configuration setting that causes Miva Merchant to set the basket cookie on HTTPS page hits. I'll discuss it internally with Rick and maybe we can get something into the next release.

[Brandon MUS]

Re: Issue With Miva Merchant Cookies - Please Verify

Brandon,

But wouldn't all of this be moot if you don't use the Basket_Session cookie? I don't quite understand what value that brings. Basket:cust_id is quite adequate for determining if the shopper is logged in or not. And, if you are using BillTo email as login (like we are) a simple lookup in the orders table will determine if they already have a login. (This test can also be extended to include previous orders, but you would want to ASK the shopper first.) Alternately, you can query the Customer Database for matching password email, shipping or billing email. Again, if this is found, you'd probably want to change the message to specifically ask permission. There may be a reason they DIDN'T want to log in.

Maybe there's a little confusion. I'm not having any problems on INVC (I do exactly how you describe, check for a cust_id -- I think I actually check order:cust_id, but same results I imagine). This whole problem happens after INVC once they do fill out the form to create an account and carry on with whatever they're doing. Once off of INVC and back into the normal site, without the basket-id cookie (session_id), how do you know what basket is assigned to the user? And without the basket how can you tell if a customer is logged? Once the customer leaves the INVC screen having created an account (or not really), there's nothing available to identify them. The only value you have is an old basket id that no longer exists.