[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: [mv] users Session getting mixed up with another
This is covered in the archives, search for wideopen.
This is a problem with 3.12 and earlier. To fix upgrade to the newest
version.
The newer versions of minivend use a seperate database to list all session
ids so that one is never used more than once.
I found in my case that the people who were seeing the same session, were
directed to my site from a search engine which captured the full url which
included the session id.
I did not upgrade to a newer minivend though because of other modifications
I had made to the modules, instead I added 1 line to session.pm:
sub read_session {
my($s);
# DEBUG
#Vend::Util::logDebug
#("read session id=$Vend::SessionID name=$Vend::SessionName\n")
# if ::debug(0x20);
# END DEBUG
$s = $Vend::SessionDBM{$Vend::SessionName};
# DEBUG
#Vend::Util::logDebug
#("Session:\n$s\n")
# if ::debug(0x20);
# END DEBUG
$Vend::SessionID = random_string() unless $s; # <<<< THIS IS THE ADDED LINE
return new_session($Vend::SessionID) unless $s;
$Vend::Session = evalr($s);
die "Could not eval '$s' from session dbm: $@\n" if $@;
$Vend::Session->{host} = $CGI::host;
# The below can die if there is an override and the hosts/checks
# don't match
check_override();
$Vend::Session->{'arg'} = $Vend::Argument;
$Vend::Session->{override_check} = $Vend::Session->{'time'};
$::Values = $Vend::Session->{'values'};
$::Scratch = $Vend::Session->{'scratch'};
$Vend::Items = $Vend::Session->{'items'}
= $Vend::Session->{'carts'}->{'main'};
}
Always make a backup of any module you edit!
minivend will have to be restarted for it to take effect.
And also the session will have to be expired. The best thing to do is to expire
all sessions late at night (or when no one is currently shopping)
What this does is assign a new random session id if the id does not currently
exist. It has taken care of my problem because once the session is expired,
then any hardcoded link which contains a session id will link to the cart but
the user is immediately given a new random session id.
I suppose there is still a remote possibility of a random session id matching
a current session id, but I think the odds are better for the state lottery!
I would advise if at all possible to go the upgrade route, once you start
modifying
these modules you may come to a point where an upgrade will be a big headache.
Although this modification would not matter in an upgrade, because there is a
fix in the upgrade that covers this point.
Kyle Cook (KC)
At 03:10 PM 10/11/99 +0100, you wrote:
>****** message to minivend-users from macky@staktrading.com ******
>
>Hi All,
>I have people reporting that they see another user logged in when
>browsing our site.
>I have checked the log and it seems that the session number gets
>changed to that of another user.
>This is a bit of a risk as if the user has entered an address and/or
>card number, the other user will see it.
>
>Could this be anything todo with caching of pages with sessionID?
>I have only seen this since I have taken the pages out of frames.
>Macky..
>
>somebody.co.uk - - [11/Oct/1999:10:15:15 +0100] "GET
>/shop/images/contact.jpg HTTP/1.0" 304 -
>"http://online.com/cgi-bin/shop/order?hASFBaMz;27273;810" "Mozilla/4.0
>(compatible; MSIE 5.0; Windows NT; DigExt)"
>
>somebody.co.uk - - [11/Oct/1999:10:15:15 +0100] "GET
>/shop/images/customer.jpg HTTP/1.0" 304 -
>"http://online.com/cgi-bin/shop/order?hASFBaMz;27273;810" "Mozilla/4.0
>(compatible; MSIE 5.0; Windows NT; DigExt)"
>
>someonelse.ac.uk - - [11/Oct/1999:11:54:21 +0100] "GET
>/cgi-bin/shop/contactus?hASFBaMz;;683 HTTP/1.0" 200 9768
>"http://online.com/cgi-bin/shop/scan/sf=CATEGORY/sf=KEYWORD/se=MEMORY-GENERI
>C/se=QL?JxthrmfY;;97"
>"Mozilla/4.5C-SGI [en] (X11; I; IRIX 6.5 IP22)"
>
>someonelse.ac.uk - - [11/Oct/1999:11:54:55 +0100] "GET
>/cgi-bin/shop/contactus?JxthrmfY;;129 HTTP/1.0" 200 9768
>"http://online.com/cgi-bin/shop/contactus?hASFBaMz;;683"
>"Mozilla/4.5C-SGI [en] (X11; I; IRIX 6.5 IP22)"
>
>
>-
>To unsubscribe from the list, DO NOT REPLY to this message. Instead, send
>email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
>Archive of past messages: http://www.minivend.com/minivend/minivend-list