[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
[ic] CookieLogin Yes
Quoting Ed LaFrance (edl@newmediaems.com):
> At 04:34 AM 6/9/2002 +0000, you wrote:
> >Well - I guess I will have to diable CookieLogin for now, and come back to
> >it later. All other shopping cart functions are working flawlessly when
> >going to the secure server and checkout.
> >
> >in UserDB.pm there are several tests like so:
> >
> >if ($Vend::Cfg->{CookieLogin} and
> >(!$Vend::Cfg->{DifferentSecure} || ! $CGI::secure)
> >)
> >
> >when testing for cookies on a secure server. I haven't been able to track
> >them all down yet.
>
> The DifferentSecure directive is undocumented, but I'm guessing from the
> code in UserDB.pm that is was intended to be an indicator that secure and
> nonsecure domains for the catalog are different, in which case automatic
> login would be disabled.
>
> In your case secure/nonsecure domains are the same, so I'm not sure what to
> say. I suggest you inquire with your server admin, and failing that (i.e.:
> YOU are the server admin), you could search the mail archives for the
> periodically-posted SSL FAQ's as well as check the online documentation for
> clues.
>
> Is the intended configuration (ssl login), is a cookie being set on your
> client machine at all?
>
This is just one of the ways in which using different domains for secure
and non-secure is problematic, and why we don't support it.
You can always set the cookie twice; make the destination be secure,
but direct the user to a non-secure page next that sets the cookie
again. Another option would be to do an image served by an IC
page that sets the non-secure cookie.
If the user's browser is configured to accept all cookies, then
you can use CookieDomain. But that is not as common these days.
--
Mike Heins
Perusion -- Expert Interchange Consulting
phone +1.513.523.7621 <mike@perusion.com>
I don't want to get to the end of my life and find I have just
lived the length of it. I want to have lived the width of it as
well. -- Diane Ackerman