Kryptronic Software Support Forum

ok, thank you - but am i not right when I say that every visit is unique and has its own sid? if so how can an sid from this morning be followed by a customer in the afternoon? urls just don't get indexed that quickly.

would it work if we cleared the sessions file every hour or so? if so can we automate the empying of this file?

I really need this addressing and could do with some help on this.

Ok, I therefore need someone to help me sort this out. Can you guys do anything for me?

http://www.google.com/search?hl=en& … =&aqi=

As has been posted elsewhere in the fora getting rid of any hard coded SID= values requires that you go through your skin, all of your includes and any web pages within CCP you've created looking for a hard coded link that has a SID= value.  Given the large number of links that have been indexed there has to be some somewhere.  They would have gotten there by mistakenly hard coding a link instead of using the functions CCP provides to build links.

I know I am a broken record but I keep voting for cookies.  This data should be stored in cookies period.  This would totally eliminate the issue for search engines because search engines don't read cookies.  Try shopping at Amazon, Newegg, eBay, log into your bank, etc with cookies off - no go.  The argument against cookies because it might effect a few people from shopping is flawed IMO.  As I stated you can NOT shop at major etailers with cookies off nor can one log into most mail systems (like Yahoo!, Hotmail, AOL), try logging into Facebook, MySpace, etc, do online banking, etc without cookie support.  Cookies are a fact of life in this modern age and CCP needs to adapt with the modern times.

As for the URL indexing I can't speak for your site davek but on many of ours (like our blogs) we have had stuff indexed and appear in the SERPs (search engine result pages) in less than 30 minutes.  It all depends on how the SE's visit and view your site's content and quality.

cyberws wrote:

I know I am a broken record but I keep voting for cookies.

The SID information IS stored in a cookie and has been from day one of CCP version 6.

good question....

I'm with Jeremy on this one... if the flip side of making the site work for users without cookies is a possible privacy violation by having a URL with an SID value crawled or otherwise disseminated, then it just isn't worth it.  This is not a hypothetical, as there have already been several well documented cases where URLs with SID values were copied by site visitors and disseminated in emails, posted in fora or otherwise propagated through no fault of the CCP site owner/designer and completely beyond their control.  Given that private information is revealed when this occurs and the risk cannot be entirely controlled by the shop owner/designer, no matter how careful their practices, there really is no other conclusion except that it IS in fact a fundamental issue in CCP - it may be too strong to call it a "flaw", but it is certainly a major design weakness.  I will be the first to grant that 99% of these cases are screw-ups by the shop owner, and I expect this case is no different, but the fact remains that the SID-in-the-URL method of controlling sessions is a very bad idea without some other checks to validate that the session actually belongs to the person accessing the site currently and not some random other person following a bad URL.

Last edited by rachaelseven (06-12-2009 11:26:36)

cyberws wrote:

Dave>  Well it shouldn't be included in the URLs.  The system should simply read the SID information from the cookie only instead of inserting it into the URLs which people often copy.

I have once again pointed Nick to this discussion and suggested alternatives which have been discussed here and in other threads.  I have no direct influence on what he does however.  We'll have to wait and see if anything changes.

Thanks Dave.  I know you can't make those choices as it falls on Nick's lap and I appreciate you bringing it to his attention for the x time.

I know I posted this on the release notes thread, however I find it so annoying about the database changes.  I know new database columns and tables get added to evolving software and that is expected.  However this constantly changing table schemes is NOT cool.  I was told by Nick when CCP 6.x was going to come out that tge new at the time layout was the way of the future.

I had to go through and code my SQL calls in all my various scripts, as we use a lot of external scripts to call to the CCP database for all kinds of automation.  I did and was assured that future versions would use the same table structure, again with new column additions, but the underlying table names were good for versions to come.  Now with 7.x we are faced with having to scan through dozens of scripts simply to change table names and SQL statements.  This is NOT cool.  Other than CCP I don't know of any software that has such radical changes in database structure from version to version.  Nothing I can think of changes the underlying table names.

Well CCP is the only system that keeps requires these types of changes.  I will say from a DBA stand point messing with table names isn't a good idea.  There is no reason why there just can't be say an order table from the beginning and leave it alone.  I guess we have to disagree on this is a trivial issue.  I know it is changing regardless but that's how I see it.  The database scheme is "unstable" in CCP.  As mentioned Wordpress (as an example) doesn't keep changing their user table name with every major release.  Wordpress has used the same table definitions however every major version of CCP is a changing in structure.  There is no reason for a table name change.  It isn't like name a is "better" than b.

Some changes are unavoidable but the database is a separate layer and it should be left alone short of add new columns or new tables.

P.S. I give a lot to CCP.  It is very good software over all and my hat is off to Nick in security.  As CCP stands shoulders above most software on security and speed.  Many PHP scripts of this size are bloatware.

Last edited by cyberws (06-12-2009 08:26:18)

Argh... Well I am not going to drone on but I don't have to keep changing scripts that work with other products due to major database changes.  No software should keep renaming tables.  In general all software should make as little changes to the database period.  Even adding a column creates problems as the database server MySQL, PostgreSQL, Oracle, MS SQL, etc have to move data around to make room for the new changes.  Plus any database server while altering a table must freeze access to that table.  So while that table is being altered nothing can occur to that table.  There are ways around this if you run a database cluster.

There is no reason these tables names need to keep changing.  Function calls fine things change.  Database scheme changes no.  Any altering of tables can result in gotcha's.