Yes I know, another HTTP_REFERER effort. I cringe when I see it. But it has been handed to me as a solution to a 'go back' problem and it actually works, so...
...the problem is, I don't understand it enough to feel comfortable deploying it live.
I've gone through many many messages here about the perils of HTTP_REFERER, however I am told this code addresses them for this particular task... but I'm not convinced.
So, my Questions are at the bottom of the code below - but FIRST, here is the basis behind it:
This code goes into a shopping cart. It provides the action of the 'Continue Shopping' button after a user clicks 'view cart'. Its goal is to provide the most suitable (or, expected) redirection back to where the user came from.
By default, without this code added, the 'Continue Shopping' button of this particular 'view cart' page simply takes the user to the home page of the cart - which sort of blows if the user has navigated a few pages deep to find a set of products or a specific category, or was looking at a product, etc. So we want to improve on that. Also, the cart requires javascript to complete a purchase, which the user is warned of if they visit with JS off, so JS on is expected of the user during this operation. Finally, we wanted to keep the solution to a single block of code, so it can be applied easily and transported to updated versions of the cart with little issue.
The methodology as it was described to me:
If a referer is set AND it is not empty AND yes it DOES contain this c开发者_如何转开发art's domain then
1a. If the referer is the cart page itself, apply a javascript (-1) effect otherwise we'll be stuck in one place
1b. ELSE go ahead and apply the Referer - Done.
ELSE if a refer is set AND it is not empty BUT no it does NOT contain this cart's domain then
2a. Something is amiss, send them to the home page. (?? why ??)
2b. ELSE let's apply the javascript (-1) effect. - Done.
The code:
if ((isset($_SERVER['HTTP_REFERER']) && !empty($_SERVER['HTTP_REFERER']) && (strpos($_SERVER['HTTP_REFERER'], HTTP_SERVER) === 0))) {
if ($_SERVER['HTTP_REFERER'] == HTTP_SERVER . 'index.php?r=cart') {
$this->data['continue'] = 'javascript:history.go(-1)';
}
else {
$this->data['continue'] = html_entity_decode($_SERVER['HTTP_REFERER']);
}
}
else {
if ((isset($_SERVER['HTTP_REFERER']) && !empty($_SERVER['HTTP_REFERER']) && (strpos($_SERVER['HTTP_REFERER'], HTTP_SERVER) !== 0))) {
$this->data['continue'] = 'index.php?r=home';
}
else {
$this->data['continue'] = 'javascript:history.go(-1)';
}
}
My Questions:
Ok, so we've combined two suspect methods, and collectively it seems to work. But what can go wrong with this (Security / Function)? Is there a showstopper here that I'm missing?
What is the second part (2. and 2a.) going to accomplish? It is explained to me to be an effort to determine if someone is purposely trying to feed a false referer - but it doesn't make sense to me - why do we care to route that person to the home page vs. using the javascript (-1) method?
ANY thoughts on improvement? Those always come in handly ;-)
Thank you for your time in helping with this...
Referer is simply just the last page the user visited before going to the cart.
Javascript:history.go() contains an array of visited pages similar to referer, so it can send the user back a page in history. I don't know of what risk that is unless the cart has no timeout. But I'm not much a security person, so better to let someone with more knowledge explain the risks there.
if a user jumped from some other website directly into a cart there, then there really should be something amiss and rather than leaving them there, send them to the home page. In this case, java is a client side software, so it wouldn't have a history of browsing your site to use to send the user to your homepage.
If you really don't like referer, breadcrumbs are always another option, or $_SESSION['previousPage'] = ....
Correct me if I'm wrong.
精彩评论