[ic] Multizip and Multistate do not require

Paul Jordan paul at gishnetwork.com
Sat Jan 9 22:41:38 UTC 2010

>> >>     state=multistate
>> >>     zip=multizip
>> >>
>> >> I should mention that I do have MV_STATE_REQUIRED and MV_ZIP_REQUIRED
>> >> set
>> >> properly. With this, I was under the impression a zipcode and state
>> >> would be
>> >> required.
>> >>
>> >> If the customer is not from the US or Canada, they can get through the
>> >> checkout without having a state or zipcode. I noticed this because I
>> >> was
>> >> getting autocreate failures with sporadic German customers that were
>> >> including their postal code  prefixed on the City, and leaving the
>> >> postal
>> >> code blank.
>> >>
>> >> Anyway, to work as expected, one would really need this:
>> >>
>> >>     state=multistate
>> >>     &and
>> >>     state=required
>> >>     zip=multizip
>> >>     &and
>> >>     zip=required
>> >>
>> >> I'm submitting this to make sure this was the intended behavior, or is
>> >> there
>> >> in fact a bug.
>> >>
>> >> Just to be clear, as Standard ships, auto-creates can fail.
>> >
>> > Hi Paul,
>> >
>> > A patch was made by Mike to prevent the autocreation from failing, see:
>> > http://github.com/interchange/interchange/commit/7a238b464b153673b2233dafcb4
>> > e914e1ba5d1f8
>> >
>> > This has been backported to 5.6.2 stable branch and is part of the 
>> > current
>> > 5.6.2 download:
>> > http://ftp.icdevgroup.org/interchange/5.6/tar/interchange-5.6.2.tar.gz
>> >
>> > Only if you'd do an order desk entry you'd still run into the problem
>> > mentioned from the looks of it as there the password generation is 
>> > still
>> > based on just the zipcode.
>> Gert
>> Thank you.
>> However I noticed it is no longer using the zip for the password. Was 
>> this
>> also done for some security reason?
>> I ask because part of our RMA system has an option if they have no 
>> account -
>> they sign in with their order number and zipcode. This looks up their
>> username (UXXXX) and uses the zip for the password - which if I switch to
>> randomized password, I'll have to rework this. Most non-account customers
>> won't know their random password.
>> If there is a security risk by using zipcode then I'll make the change,
>> otherwise it can wait.
>> Paul
> I personally think it's a bad idea to use the zip as a password in any
> case.  Stores that are popular in a local area especially.  (or a
> website for a city!)  In fact, I don't even like passing the password
> back to the user over email, but it really depends on the site...  The
> big problem comes in if you are using "gift certs" or any other form of
> "credit"...  I modified my site so that if there is a gift cert in the
> cart, they would have to go through a hard-core account setup in order
> to use purchase that.  Then they can only retrieve the code by secure
> login.  Sorry to get a bit off topic...

Thanks Rick and Gert (offline response)

In my experience non logged in customers never use their account again 
because we explicitly are making them think they have no account, even 
though they actually do. If there is no account, then there could be no 
credit functions.  Auto creates are one time throw away accounts in our 

I see what you are getting at and I of course agree.

However, even with the random password, is IC still sending out the username 
and password in the email receipt? It's that very observation that made us 
treat auto creates as special, and inherently insecure.

Alas, I'll put in Mike's fix and alter my RMA system.



More information about the interchange-users mailing list