[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
[ic] Secure server FAQs [monthly posting]
On Wed, 13 Mar 2002 23:42:23 -0500
"D Zhang - msi" <dzhang@mtspring.com> wrote:
> > First of all, it is questionable business practice to not certify your
> > secure server. Besides violating the terms of use of many certificate
> > issuers, customers notice the changed domain and it is proven by user
> > surveys and long experience that you will receive fewer orders as a
> > result. Certs can be obtained for $125 US per year, less than the
> > typical cost of one hour of a top consultant's time. Do your business
> > a favor -- spend the money to get a cert.
>
> I can't agree with the above point of view.
>
> I wish that ic would not become a guaranteed revenue source of certifying
> companies.
>
If I don't see SSL, I won't buy at all. If I see SSL but uncertified I have no guarantee, that who I am dealing with is even an existing company. They can take my credit card information and order plenty of services in the internet with it and I have to run and fix it. So I go and rather choose someone else who I can make responsible if something goes wrong.
If you don't use a certificate you definitly hurt your business and probably for more than $125.
Why should web hosting only cost $150/year? Because the competition is high.
Wait for a while until all the smaller CAs are getting recognized by the browsers. I actually saw certificates for $99. How much will be justified for a certificate? How about the security of their systems.
Someday we will probably get them for $50.
How much were the first CD players?
> $125/year is a big deal. Recently, I searched the internet for hosting
> services. There are many servers offering about $150/year, with capacity
> more than enough to run interchange cart. Think of this, those servers have
> to take carry of your site for whole year. How much time, work, and cost
> does it take to issue an certificate? It got to be fair to every one.
>
> David
>
>
>
> ----- Original Message -----
> From: "Mike Heins" <mheins@redhat.com>
> To: <interchange-users@chevelle.interchange.redhat.com>
> Sent: Saturday, March 09, 2002 9:18 PM
> Subject: [ic] Secure server FAQs [monthly posting]
>
>
> > These are the FAQs:
> >
> > Shopping cart is dropped when using SSL.
> >
> > This is a thorny question. It has many possible causes, and most often
> > occurs when you try to use a different secure server domain than the
> > regular catalog runs on. (See the next question for more info on
> that.)
> >
> > If your secure domain is the same as the non-secure domain, it is
> > usually due to the user not having cookies enabled. It can be due to
> the
> > HostnameLookups (Stronghold/Apache parameter) not matching for the two
> > servers, secure and non-secure. It can also be caused by the user
> having
> > different web proxy addresses for HTTP and HTTPS. If it still does not
> > work, try changing some of the appropriate configuration parameters in
> > interchange.cfg:
> >
> > DomainTail No
> > IpHead Yes
> >
> > If you still are having problems, try this combination in catalog.cfg,
> > the catalog configuration file:
> >
> > SessionExpire 10 minutes
> > WideOpen Yes
> >
> > The above setting will typically make Interchange work when it is
> > possible to work. Sometimes when you have multiple Interchange servers
> > sharing the same secure server, you will have problems after accessing
> > the second one. (The first one issues a session ID cookie, and that
> > causes problems).
> >
> > I have a different secure server domain. Why does the shopping cart
> > get dropped?
> >
> > First of all, it is questionable business practice to not certify your
> > secure server. Besides violating the terms of use of many certificate
> > issuers, customers notice the changed domain and it is proven by user
> > surveys and long experience that you will receive fewer orders as a
> > result. Certs can be obtained for $125 US per year, less than the
> > typical cost of one hour of a top consultant's time. Do your business
> > a favor -- spend the money to get a cert.
> >
> > If you insist on doing it anyway, probably driven by the fact that
> > you need a dedicated IP address for a secure server, you can use the
> > solutions in the previous FAQ question and get some relief.
> >
> > But by far the best way is to have all orders and shopping cart calls
> go
> > only to the secure domain. Your users may get a different session
> when
> > browsing the non-secure catalog pages, but it will matter little.
> >
> > To do this on the Foundation demo, place in catalog.cfg:
> >
> > AlwaysSecure order ord/basket ord/checkout
> >
> > A more complete list might be:
> >
> > AlwaysSecure <<EOF
> > account
> > change_password
> > customerservice
> > login
> > logout
> > new_account
> > ord/basket
> > ord/checkout
> > order
> > process
> > query/check_orders
> > query/order_detail
> > query/order_return
> > returns
> > saved_carts
> > ship_addresses
> > EOF
> >
> > (Thanks to John Beima for the above list.)
> > Add pages of your own that need to be sure of coherent
> > session information.
> >
> > For all *forms* to be secure, make sure "process" is on that list.
> (Your search
> > forms will still be non-secure if you use "[process-search]" to
> produce
> > the form ACTION.)
> >
> > To make individual order links secure, use this instead of "[order]":
> >
> > <A HREF="[area
> > href=order
> > secure=1
> > form='mv_order_item=SKU_OF_ITEM'
> > ]">Order it</A>
> >
> > To make a form-based order button secure, use "[process secure=1]" as
> > the ACTION.
> >
> > My images aren't there on the secure server!!!
> >
> > You have a different document root, or the permissions are not such
> > that you can access them. You can set a different base URL for images
> > with:
> >
> > ImageDirSecure https://your.secure.server/somewhere/images
> >
> > Don't try to set it to an http:// URL -- images will be broken anyway.
> >
> > My secure pages fail when my browser is MSIE.
> >
> > MSIE has several SSL bugs, particularly in V5.01. See the
> C<Apache-SSL>
> > or C<mod_ssl> FAQ. You can sometimes fix this with an httpd.conf
> change:
> >
> > SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
> >
> > --
> > Red Hat, Inc., 131 Willow Lane, Floor 2, Oxford, OH 45056
> > phone +1.513.523.7621 fax 7501 <mheins@redhat.com>
> >
> > For a successful technology, reality must take precedence over public
> > relations, for Nature cannot be fooled. -- Dick Feynman
> >
> > _______________________________________________
> > interchange-users mailing list
> > interchange-users@interchange.redhat.com
> > http://interchange.redhat.com/mailman/listinfo/interchange-users
> >
> >
>
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com
> http://interchange.redhat.com/mailman/listinfo/interchange-users