[ic] Secure server FAQs [monthly posting]
D Zhang - msi
interchange-users@interchange.redhat.com
Wed Mar 13 23:53:00 2002
> 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.
$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
>
>