Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

[Contribution] Googlebot/Spider session id killer


Ian

Recommended Posts

  • Replies 191
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Just wondering if anyone can assist me with my allprods.php link.

 

I've decided to actually use it as part of the site, rather than just hide it somewhere... (though am doing that in the header and footer also! :wink: )

 

I've put it in my categories box (catalog/includes/boxes/categories.php) which works fine as per this example: (around line 160)

(Remove the 'img' portion if you're not running the 'all bullet images' contribution.)

tep_show_category($first_element); 

 $info_box_contents = array(); 

 $info_box_contents[] = array('align' => 'left', 

                              'text'  => $categories_string .

                              /* All Products - Start */

                              '<br><img src="images/cat_arrow_right.gif"> <a href="' . tep_href_link(FILENAME_ALLPRODUCTS, '', 'NONSSL') . '">' . BOX_CATEGORIES_ALLPRODUCTS . '</a>'

                              /* All Products - End */

         ); 

 new infoBox($info_box_contents);

 

My problem becomes apparent when you click on the link... it doesn't go bold like the standard category links do.

I think I've tracked it down to this piece of code, in the same file: (around line 40)

    if ( ($id) && (in_array($counter, $id)) ) { 

     $categories_string .= '<b>'; 

   } 



// display category name 

   $categories_string .= $foo[$counter]['name']; 



   if ( ($id) && (in_array($counter, $id)) ) { 

     $categories_string .= '</b>';

 

I'd like somehow to integrate an if statement to detect if the allprods.php file has been selected.

 

Thanks,

Tony

"The price of success is perseverance. The price of failure comes much cheaper."

Link to comment
Share on other sites

Due to the 11 page thread, it's a bit hard to work out what the current SID Killer code is... in light of this, can someone please post the current method of incorporating this into a site... to save looking through 11 pages which can get quite confusing.

 

Thanks,

Tony

"The price of success is perseverance. The price of failure comes much cheaper."

Link to comment
Share on other sites

Well it could really do with being posted as a contribution.

 

I think a number of users are holding back on doing this, becos there are so many different versions.

 

So maybe those who have been the main developers could post their versions of the SID killer and add to contributions under the name SID Killer.

 

I am not sure if Ian has even done his as yet, but I'm sure it would help a number of users if it were done this way.

 

CC.

Link to comment
Share on other sites

Hi all,

 

CC that's a good idea. I will take a look at my code tonight. As I said on another thread the last remaining problem is the handling of language changes.

 

At the moment if the language is changed my sid killer reverts to letting sid's be formed. The reason for this is that the language is held in a session and we therefore need an sid to propogate the session.

 

There are two ways of handling.

 

A) Make language selection a form action. This is straightforward, but has the drawback that it won't work with allprods.php

 

B) hack tep_href_link to propogate the language change on all subsequent Url's

 

I tend to think b is the more elegant solution.

 

There also appears to be a problem with the support ticket mod which I need to look at.

 

Once I've made those changes with Justins permission we'll post it as one single contribution.

Trust me, I'm an Accountant.

Link to comment
Share on other sites

A) Make language selection a form action. This is straightforward, but has the drawback that it won't work with allprods.php

 

B) hack tep_href_link to propogate the language change on all subsequent Url's

 

Am I right in understanding B) will result in every single url having /language/en appended to it?

 

If so I'd say A) is the better solution as it only affects one contribution that can easily be updated. Plus the language is only an infoBox, hence easier to replace.

 

Mattice

"Politics is the art of preventing people from taking part in affairs which properly concern them"

Link to comment
Share on other sites

Am I right in understanding B) will result in every single url having /language/en appended to it?

 

If so I'd say A) is the better solution

Mattice

 

Only appended if cookies are disabled. Another reason I prefer B is that is more generic. A) doesn't work with the allprods contribution, or any contribution/external link which has the language in the url. A) also means google can't spider your site in a foreign language.

Trust me, I'm an Accountant.

Link to comment
Share on other sites

Mattice,

 

To paraphrase Lemmy, no sleep till MS1 :lol:

 

Anyway. Ive finished the code changes to propagate the language on the url. Works like a dream :)

 

Unfortunately I've found another problem :(

 

This has to do with the navigationhistory class. This is stored as a session variable, and will therefore be lost when no cookies and no sid.

 

What effect does this have.

 

Consider the following. In standard osCommerce, if I click on the my account link (when not logged in) I will be taken to the login page. Once I log in I will then be taken directly to the my account page. This happens automagically because of history info stored in the navigationhistory class.

 

What happens with the sid killer is that once you log in you are dumped unceremoniously back to default.php :(

 

You can of course then go to my account with no problem

 

Remember this only happens if the user has cookies disabled

 

As of the now, I don't have any solution for this. :(

 

I'll upload the code shortly (if I don't fall asleep at the keyboard).

 

I'll also move Joshua Dechant's contribution into the same package. Which only leaves my product_listing_col mod which also uses the buy now button to be 'fixed'

Trust me, I'm an Accountant.

Link to comment
Share on other sites

This is just an innocent aside from the main argument in this thread

(sorry if it bothers the team guys)

 

Is this a big issue if the cart doesn't function well with the browsers where cookies are turned off? I mean, is there a large population out there that keeps its cookies turned off all the time?

 

If there is, then how can a guy live on the online planet without eating all those cookies on every nook and corner!

 

Just my 2c.

 

Sunny

Link to comment
Share on other sites

I am definitely not a coder, so what I suggest here may not even be feasible.

 

It seems to me that the entire format of the cart defaults to using SID or cookies, instead of it defaulting to neither unless the user does something specific which would require their use.

 

Wouldn't it make more sense to initiate SID or cookies only when an action was taken that requires them?

... if you want to REALLY see something that doesn't set up right out of the box without some tweaking,

try being a Foster Parent!

Link to comment
Share on other sites

To paraphrase Lemmy, no sleep till MS1 :lol:

 

Another truce, another race,

I'm eating junk, feeling bad,

Another night, I'm going mad,

My woman's leaving, I feel sad,

But I just love the life I lead,

Another MS is what I need...

Ian Fraser Kilminster

 

(FYI: Tenacious D plays the Manchester Apollo - 14 March... and they're coming to Paradiso, Amsterdam as well!)

 

Consider the following. In standard osCommerce, if I click on the my account link (when not logged in) I will be taken to the login page. Once I log in I will then be taken directly to the my account page. This happens automagically because of history info stored in the navigationhistory class.

 

As of the now, I don't have any solution for this. :(

 

Could'nt we just transport it on the URL as well?

I think it is a valuable feature to redirect to the proper page after a login.

 

 

Mattice

"Politics is the art of preventing people from taking part in affairs which properly concern them"

Link to comment
Share on other sites

Just as another side note, if cookies were enabled and yet when a customer clicked my account, then logged in it still took them back to default.php and not to the account.php page, what would the problem be on the site?

 

It appears that even tho Ian's mod is not installed, that effect has reared it's head for me anyway. So they never get redirected to the correct page.

 

I can say for one I dont like this happening, it is just one more click for the customer.

So it would need to be sorted before I feel it would be worthwhile. IMO.

 

And following the side note, anyone tell me what needs checking to find out why my site is doing this, cos I cant bloody find the reason why... :?

 

CC.

Link to comment
Share on other sites

Mattice spoke thus

Could'nt we just transport it on the URL as well?

 

Easier said than done. I've just been playing round with this and it is a pig :roll:

 

The only solution I can see is to rely on that wonderful thing called cvs and dig out the code that navigationhistory replaced, namely the $origin link.

 

However as this is such a big change for a small return (remember we are only talking about customers with no cookies)

I think I'll post that as a separate contribution (although in the same contribution package).

 

OFFTOPIC

Was watching classic rock channel the other night. Our friend Lemmy in his Silver Machine/Hawkwind days.

Trust me, I'm an Accountant.

Link to comment
Share on other sites

Steve I am having the same problem.

Ever since I installed the sid killer, customers log in and are directed back to the default page with Welcome Guest as if they hadn't logged in.

Don't know how to get around this :(

Link to comment
Share on other sites

Ian;

 

Easier said than done. I've just been playing round with this and it is a pig

 

The only solution I can see is to rely on that wonderful thing called cvs and dig out the code that navigationhistory replaced, namely the $origin link.

 

However as this is such a big change for a small return (remember we are only talking about customers with no cookies)

I think I'll post that as a separate contribution (although in the same contribution package).

If I'm not mistaken, I've run into the problem even though I have cookies enabled in my browser. I guess it's possible that I've balled something up elsewhere, but without SID Killer in place, everything functions as I would expect it to, then I put in SID Killer and start having redirection problems - some of them resulting in an endless loop.

... if you want to REALLY see something that doesn't set up right out of the box without some tweaking,

try being a Foster Parent!

Link to comment
Share on other sites

Muggity,

 

With the sid killer not installed, do you get SID's on the links/URL.

 

BTW the SID killer doen't actually kill SID's per se. It just stops them being attached to links. The SID is still available to be stored in a cookie.

Trust me, I'm an Accountant.

Link to comment
Share on other sites

Yeh it seems to be a bugger of a problem.

 

The SID killer works fine for me, but the redirection is not going to the page it is designed to go to, i.e. account.php even with cookies enabled.

 

It is giving opur visitors one more click than is needed.

 

CC.

Link to comment
Share on other sites

hmmmm...

 

This is strange.

The SID Killer is working for all my links, but I have google crawling my site right now, and the odd login.php WITH SID is being generated sometimes.

All other links are fine, but I am still giving google a SID for the login page. Whereas with the previous SID killer I was using this didnt happen.

 

I have altered all buy now links to forms, and all other things I can think of...

Anyone got any ideas what might be linking google to login.php, and also I thought the SID was not issued until a user was LOGGED in not on the login page??

 

CC.

Link to comment
Share on other sites

That's just the way google works.

 

Sometimes it may take Google several recussions of their crawl to weed out bad links. And actually, since it can still get to links with the SSL, although they are not what the customer is looking for, it will still think that they are valid.

-------------------------------------------------------------------------------------------------------------------------

NOTE: As of Oct 2006, I'm not as active in this forum as I used to be, but I still work with osC quite a bit.

If you have a question about any of my posts here, your best bet is to contact me though either Email or PM in my profile, and I'll be happy to help.

Link to comment
Share on other sites

Hi Steve,

 

The sid is added back as soon as we hit the login page. The reason for this is that we need a session in place to register the customer_id.

 

This also means that all your header and sidebox links will now have sid's in them. :cry:

 

One suggestion was to kill all your sideboxes when on login.php but seems a bit drastic.

I think there is a simpler fix for this which I'm testing now. Let you know how it goes in a bout 1 hour.

Trust me, I'm an Accountant.

Link to comment
Share on other sites

Thanks for the comments Chris, I had not remember that.

 

I'll keep my eye out for the update too Ian.

 

In the meantime I think I will just drop back to my previous SID Killer until it's sorted.

Yours is a much better solution, but aint it just sods law google crawls us right now!! :roll:

 

I'll be back! :lol:

 

CC.

Link to comment
Share on other sites

Ok,

 

I've tested the fix and all seems well.

 

In the application_top.php code change the line

 

if (basename($PHP_SELF) == FILENAME_LOGIN) $kill_sid = false;

 

to

 

if ((basename($PHP_SELF) == FILENAME_LOGIN) && ($HTTP_GET_VARS['action'] == 'process') ) $kill_sid = false;

 

and immediately following add

 

if (basename($PHP_SELF) == FILENAME_CREATE_ACCOUNT_PROCESS) $kill_sid = false;

 

I'll post an updated contribution later today.

 

:)

Trust me, I'm an Accountant.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...