[ic] Secure server FAQs [monthly posting]

[Mike Heins <mheins@redhat.com>]

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