osCommerce 2.3 is officially available

A flurry of activity from Harald and Mark saw osCommerce 2.3 released yesterday. The download link can be found on the official osCommerce site at http://www.oscommerce.com/solutions/downloads

A quick overview of new features available in the new osCommerce is as follows;

  • Modular Action Recorders to log and limit certain functions, including:
    • Administration Tool login attempts
    • Tell A Friend e-mails
    • Contact Us e-mails
  • Security Directory Permissions for the Administration Tool shows which directories are writable
  • Version Checker for the Administration Tool to check for new versions
  • Modular Social Bookmarks to share products on social sites, including:
    • Facebook and Facebook Like
    • Twitter and Twitter Button
    • Google Buzz
    • Digg
  • PayPal Express Checkout pre-configured for new store owners
  • Guest orders through PayPal Express Checkout
  • Modular Header Tags for optimizations, including:
    • Google Analytics and E-Commerce Tracking
    • MailChimp E-Commerce 360
    • OpenSearch
  • New separated XHTML/CSS based template
  • jQuery UI design
  • 960 Grid System CSS Framework
  • Password hashing algorithm changed to Portable PHP hashing for customer and administrator passwords
  • Security Check modules for add-ons to check on server requirements
  • Administration Tool Dashboard widgets, including new charts
  • Modular Boxes to inject content anywhere in the HTML layout
  • Multiple Product Images with large images and HTML content for Flash videos
  • New Payment Modules, including:
    • PayPal Website Payments Pro and PayPal Express Checkout
    • Moneybookers
    • Sage Pay

Go ahead and try it. I’m sure you will be pleased with the majority of it. I’ll go into more depth on some of my ideas for it in some upcoming blog posts.

Well done Harald and Mark. Well done to that handful of the osCommerce Community who helped to find bugs and solve them.

This marks the beginning of a new era for osCommerce. Now that 2.3 is out, there will be a 2.3.1 to mop up any important changes. Then full concentration can go to bringing osC 3 to market.

52 Replies to “osCommerce 2.3 is officially available”

  1. Downloaded it tonight currently trying to get it running without errors on my local – my osC headache is returning – no it has returned with a vengeance.

    I’m not really complaining but I wonder if the amount I am now chewing is too much for me at one go. I know now, if I didn’t before, that not keeping on top of changes can be fatal to MY memory cells. Anyway I personally would have preferred an update to a total secure osC and then the update to div – I liked tables – I knew how they worked 😀 I’m sure divs are better though – when I eventually get my head around them lol

    Oh well back to the text wrangling – any tutorials would be welcome especially a div version of Design a Great osCommerce Site please Gary

  2. Will. Me too. RIP Bobby.

    Julian. Tables are still OK when used correctly. Using tables to make a design work was a hack at best even 10 years ago. The move away forces us all to work to better standards. If there is enough call for a book, I’d consider writing one.

  3. Hi Gary

    Thanks for the reply, I know divs are the way forward – my problem Saturday was trying to get it to work not only on XAMPP but with my original database, but after multiple attempts to log in on the admin side – won’t allow me in even with the correct password, I’ve even deleted the admin from the db and gone through the new admin process and it still refuses to recognise user & password – anyway I’ve given up for the time being – on XAMPP that is – and have clean installed on-line – now it does work 🙂

    I think bookwise, yes there is call – well I think so – at the least an addendum to existing publications to show the difference between 2.2 and 2.3 after all 2.3 is a little more than a security update – there is a change in – not so much layout but how that layout is achieved and certain things that were done on 2.2 to tweak it may not (probably won’t) work on 2.3 and your Design a Great osCommerce Site guide with divs will go a long way to showing the differences between the two, in fact any non-in depth publication showing the difference between 2.2 and 2.3 will be appreciated.

  4. As far I know the admin login issue is an osCommerce bug. The culprit was always there at least as far as 03. Things got worse though with the RC versions – because of the login page – it manifests itself in a different way now. It can be intermittent or consistent and it is subject to the PHP, server environment. There are 2 reasons this is happening.

    The first is because the admin end of the osc, issues redirects then exits, without closing sessions. In other words after you sent the redirect headers you need a tep_exit instead of the plain exit (do not rely on PHP to auto close sessions). That will fix the current problem members report (see function tep_redirect).

    The second is not common but it may happen because of the way the session string is sanitized see:
    session.hash_bits_per_character and session.hash_function
    http://docs.php.net/manual/en/session.configuration.php#ini.session.hash-bits-per-character
    a) The filtering code in sessions.php allows only alphanumeric characters. But the manual includes other characters,
    b) the number of characters in the session is defined by the session.hash_function it maybe other than 32 in length subject to how the php is configured. The db column sesskey is fixed to 32 chars.
    c) the session validation should happen against stored sessions with the database, not against an input string because that can cause session fixation/poisoning.

    hth

  5. Mark – thanks. Are you raising this as a bug ot the forum? Or would you want me to do that?

    Readers – tep_exit does not exist in the admin side, so;

    1. open up admin/includes/functions/general.php, add this at the bottom before the final ?>

    function tep_exit() {
    tep_session_close();
    exit();
    }

    2. same file, find this (about line 40):
    exit;
    Change it to this:
    tep_exit();

    See if that helps the situation.

  6. In my localhost server php.ini file, I have this;

    session.hash_bits_per_character = 5

    So, my sessions can presumably use “0” thru “9” and lowercase “a” thru “v”.

    session.hash_function = 0

    which is 128 bits.

    I wonder what XAMPP is set to, Julian could you check the php.ini file (should be \xampp\php\php.ini).

  7. The php.ini file was in xampp/xampfiles/etc and contains no session.hash_bits_per_charactor or session.hash_function

    I’ve tried the above tep_exit fix by Gary which didn’t work but I think in all fairness I should retry with a clean install and see how it works then – it won’t be until tomorrow though as I’ve just done a 250 mile 5 hour drive – oh how I hate the south coast roads 🙁

  8. Hi,

    This is how I fixed my log in problem in 2.3

    Not sure if it will work for everyone or if it was the right way to go about it but it worked for me.

    First I emptied the administrators in my database & it allowed me to create a new one, of course this didnt work when I tried to log in.

    Then I emptied the sessions in my database this worked but not for long, then I ran this SQL (It is from the install SQL)

    DROP TABLE IF EXISTS sec_directory_whitelist;
    CREATE TABLE sec_directory_whitelist (
    id int NOT NULL auto_increment,
    directory varchar(255) NOT NULL,
    PRIMARY KEY (id)
    );

    DROP TABLE IF EXISTS sessions;
    CREATE TABLE sessions (
    sesskey varchar(32) NOT NULL,
    expiry int(11) unsigned NOT NULL,
    value text NOT NULL,
    PRIMARY KEY (sesskey)
    );

    Login is now working!

  9. I don’t think removing/adding db tables does anything. The problem can be very well intermittent. After you apply the changes for the tep_exit, clear the cookies and cache of the browser.

  10. I don’t know either, all I know is Ive been able to log in every time since. I had nothing but trouble before, its working for now, thats the main thing 🙂

  11. Julian

    “The php.ini file was in xampp/xampfiles/etc and contains no session.hash_bits_per_charactor or session.hash_function”

    Can you add them, then shutdown and restart the server. See if it helps.

    session.hash_bits_per_character = 5
    session.hash_function = 0

  12. Added the tep_exit()-function as described and added

    session.hash_bits_per_character = 5
    session.hash_function = 0

    via catalog/admin/.htaccess

    Login still not possible.

    Regards,

    Uwe

  13. Uwe – please provide more details about your server environment. linux or windows. php version etc etc. The more detail you provide will help to solve this.

  14. @Uwe
    See if you can login when you change the session filtering on the admin end. Open your admin/includes/functions/sessions.php should be at line 99 comment out this code

    tep_redirect(tep_href_link(FILENAME_DEFAULT, ”, ‘NONSSL’, false));

    If it doesn’t work, can you also see what is the format of the session id? How many characters? Does it contain anything other than alphanumeric chars?

    To see the id, block the cookies from your browser, then the osCAdminID parameter should show with the urls. But see if you can login with the change first.

  15. commenting out only that line may not work because there is also code to unset the cookie so it will generate another one. In that same file replace the tep_session_start function with:

    function tep_session_start() {
    return session_start();
    }

    To make sure the session starts and the cookie is not deleted.

  16. Hi,

    1. commented out tep_redirect(…..)
    -> no success

    2. session-id has 32 characters, lowercase and digit only

    3. commenting out all code in tep_session_start() except the line

    return session_start();
    -> no success

    4. made another observation:
    when accessing
    http://MYSHOPURL/admin/
    I am directly redirected to
    http://MYSHOPURL/admin/login.php?action=process&osCAdminID=%5B%5B:lower:%5D%5B:digit:%5D%5D{32}

    5. I also tried cleaning table sessions in the db and deleting the cookie in firefox after making the changes described above

  17. @Uwe, Ok then it could be the setup of the server with where the sessions are saved. Backup your admin/includes/functions/sessions.php, then get this file extract it and replace the sessions.php file and see if it works.

    http://demos.asymmetrics.com/pub/sessions_moded.zip

    If it does work, then change this line in that file,

    define(‘SESSION_PHP_HANDLING’, ‘false’);

    to

    define(‘SESSION_PHP_HANDLING’, ‘true’);

    If after the change is still not working then it’s the host that hasn’t setup the session path correctly.

    You will need the original change in general.php with the tep_exit that ensures the sessions close for redirects.

  18. Neither “false” nor “true” is working. I will look into that session path thing tomorrow, although I dare to doubt that being the cause.

    Did I mention, that I have a v2.2 RC2a running seamlessly on the same server?

  19. O.k. here’s the sequel:

    After doing all of the above, I receive a sequence of errors like this:

    Warning: session_start(): open({ROOTDIR}/oscommerce-2.3.1/catalog/includes/work//sess_b1c654f89a32d98fff719190997db239, O_RDWR) failed: Permission denied (13) in {ROOTDIR}/oscommerce-2.3.1/catalog/admin/includes/functions/sessions.php on line 83

    so I

    chmod 757 {ROOTDIR}/oscommerce-2.3.1/catalog/includes/work/

    to allow apache write access to this directory. The session errors are gone then, but still no login possible.

  20. @Uwe ok, it could be the password generation/validation that fails in the admin/login.php there is this code:

    if (tep_db_num_rows($check_query) == 1) {
    $check = tep_db_fetch_array($check_query);

    right below add these 2 lines to see if the execution reaches that point when you try to login.

    print_r($check);
    exit();

    As of the php version I tried it with php 4.4 and there is no problem.

  21. One other thing I noticed and it is a bug in 2.3 and 2.3.1, is after the installation the configure.php files, both on the admin and catalog, have the DIR_FS_CATALOG definition with a double trailing slash. Now with the environments I am testing on, I do not see the admin login issue but on different environments this may create problems.

    So make sure there is a single trailing slash for the DIR_FS_CATALOG and the same may happen for the session path which is stored in the database.

  22. print_r($check); is executed

    Array ( [id] => 1 [user_name] => adminname [user_password] => [[:lower:][:digit:]]{32}:ea )

    All paths have a single trailing slash, includes/configure.php also says:

    define(‘HTTP_COOKIE_DOMAIN’, ”);
    define(‘HTTPS_COOKIE_DOMAIN’, ”);
    define(‘HTTP_COOKIE_PATH’, ‘/’);
    define(‘HTTPS_COOKIE_PATH’, ‘/’);

    Might be interesting, dunno…

  23. Hello,

    I am running into exactly the same problem as Uwe since last Friday (19th). Web hoster upgraded to PHP5.3 (from php5.2) beginning of November. All was working fine except for the few deprecated function warnings until sunddenly I could not login any longer. Web hoster says no further changes to their server since beginning of Nov upgrade.

    I have tried all the changes and actions suggested to Uwe, but not working either… still no login possible. Not sure if Uwe has found a way to fix the problem, but if he has please help

  24. got it working, you might try to find this (found on a french forum), it fixed it:
    in admin/includes/functions/html_output.php
    rewrite as follows (supposing you have the same version)…

    function tep_href_link($page = ”, $parameters = ”, $connection = ‘NONSSL’) {
    global $link;
    if($page == ”) { $page = basename($_SERVER[‘PHP_SELF’]); }
    (keep the rest unchanged)

    and it should work (did it for me)

  25. sorry forgot to mention, I also modified the admin .htaccess for it to work:

    php_value session.use_trans_sid 0
    php_value register_long_arrays 1
    php_value register_globals 1

  26. @Uwe ok, in your admin/includes/application_top.php comment out these 2 lines and try it.

    $redirect_origin[‘auth_user’] = $HTTP_SERVER_VARS[‘PHP_AUTH_USER’];
    $redirect_origin[‘auth_pw’] = $HTTP_SERVER_VARS[‘PHP_AUTH_PW’];

    This is something I could not replicate earlier, basically the default code will not process the login form if it sees there is authorization by other means, like .htaccess in place. See after commenting out the code you can login.

  27. Out of interest, are people seeing this on a clean installation of 2.3 IE exactly as installed or are people upgrading from an existing 2.2 RC2a database?

  28. I’m wondering if the people with login problems are securing the admin area using the normal htaccess/htpasswd using cpanel or similar? I vaguely recall having some issues months back when the new htpasswd system first came out…

  29. I think apart of the sessions issue, the fact the 2.3.1 checks the PHP_AUTH_USER and PHP_AUTH_PW could explain these issues. If the host’s password is different than the osc one then the variables would be populated and be different than the ones osc has in the database.

    This in turn will fail the login because the code automatically fetches the aforementioned variables and tests them with the dbase. So when they clear up the db tables they may enter the same user/pass which could then allow them to login.

    But I do not see though why the change in the tep_href_link makes a difference neither the installation change because there are reports of people not able to login even when they clear the tables.

    If you comment out the PHP_AUTH_USER and PHP_AUTH_PW clear the cookies of the browser and then try to login. So normally you will get the first popup from the host and then the login page which will process whatever you enter in the login form because the authorization variables are commented out.

  30. OK. More testing. Installed new osc, but left the admin password field blank. Shop installed. Tried to login and get “Error: Invalid administrator login attempt.”…

    Open up phpmyadmin. Go to administrator table – although the admin password field was left blank phpmyadmin shows:

    Username: admin
    Password: 5435c69ed3bcc5b2e4d580e393e373d3:ca

    So. Empty the admin table, and then go to the admin/login.php page. Asks to create an admin. I stick in “admin” as the username and “password” as the password (obviously both without quotes). This shows me in phpmyadmin;

    Username: admin
    Password: $P$Dn.4iZ6INLGA2cravrrggRIFH2FORW1

    And I can now successfully use admin/password to log into the admin section. So, I think that Gnidhal in the oscommerce forum may be onto something.

    What I would ask is that those who cannot login, go into phpmyadmin, then administrators table, and see what the password is. An idea might be to change the username and password to the 2nd lot that I have posted and then try to login.

  31. o.k. now I can login.
    – I commented out the two $redirect_origin-lines
    – I also commented out print_r / exit in login.php
    the login-history on the dashboard shows invalid login attempts, the username of these invalid attempts is the one, I use in .htaccess to restrain access to /admin-directory. So there must be a conflict between these two authentication methods.
    Hope you can squish this bug now.

    Regards,
    Uwe

  32. @Uwe yes, IMO what I described earlier is the root cause of the problem, basically the user/pass entered from the first login are taken directly from the osc 2.3.1 and used for the login form. So if the 2 pairs of credentials are different or different because of the server environment the code will still apply them to the login form.

    Just commenting out these 2 lines should be sufficient and won’t alter anything in terms of security.

  33. I tried all of the above and nothing worked except for “Comment by Gary — November 21, 2010 @ 5:41 pm” and that worked a treat. I then changed the password to what I wanted it and it works fine now.

  34. For me the problem (2.3.1) was caused by the HTTP authentication handling. If I comment out a few bits of code (2 pieces in application_top.php, 1 in login.php), the problem goes away for me. I guess someone thought it would be a good idea to use the http auth credentials instead of the form data if they were available, but it just doesn’t work if your http auth credentials are different from your osc administrator credentials – as mine are.

    My edits were in application_top.php to comment out the if block underneath ‘// try to automatically login with the HTTP Auth….’ in its entirety. I also changed the only other line containing ‘auth’ on a ‘nuke it from orbit basis’, but commenting out the test and replacing it with ‘false’ might be superfluous:
    ‘tep_redirect(tep_href_link(FILENAME_LOGIN, (false/*isset($redirect_origin[‘auth_user’])*/ ? ‘action=process’ : ”)));’

    In login.php I commented out all of the case ‘process’: block except for the two lines in the ‘else’ – the ones that assign username and password sensibly.

  35. Thanks to the explaination of Sean ( Comment by Sean — January 13, 2011 @ 5:32 pm) it works now for me too.

    Somehow the Auth_user part farts on the login part.

    Thanks Sean!!

  36. Hello. I’m new to the osCommerce (2.3.1) platform. I have successfully built the majority of the site and I’m currently in a testing mode. I have notice that in order to successfully login (either as test user account or admin account) requires three login attempts.

    I have read the dialog above, but remain unclear to the unanimous conclusion on how to resolve. Can someone please point me in the right direction?

    thanks in advance…
    Shawn

  37. Shawn – having to login 3 times is not correct, so I would suggest that you configure.php file is incorrect somewhere…

  38. My hosting company has just upgraded to PHP version 5.3.8 and MySQL version 5.0.92-community
    I installed a new version of OScommerce 2.3.1 and cant login, only the first time.
    I have tried all the fixes here, they dont work for me, BUT i did notice …
    1. If you delete all the administrators in the administrators table and login entering a new login and password, it will store them ok, password is encrypted.
    2. If you do this again, the stored password is different, even though it was the same one.

    ??? where does the encryption come from ? Shouldn’t it be the same each time ?

Leave a Reply

Your email address will not be published. Required fields are marked *