Jump to content

ecartz

♥Ambassador
  • Content count

    3,735
  • Joined

  • Last visited

  • Days Won

    62

Posts posted by ecartz


  1. They are almost certainly false positives.  The first one is simple.  Try it.  If it shows the alert, then there is a problem.  Find out where it displays and add the call to htmlspecialchars. 

    The second is more difficult, but less likely to be a problem.  Because the software already sanitizes all input before use.  It's barely possible that you have installed something that doesn't (probably not Ultimate SEO URLs).  But certainly core already does that. 

    3 hours ago, rule said:

    Solution: all user-supplied parameters should be checked for illegal characters, such as a single quote ('), before being used in an SQL query.

    This is not the approach that osCommerce takes.  Instead, it sanitizes all parameters before using them in a SQL query.  In the case of a product ID, this would typically happen via a cast to int.  For strings (including the extended product IDs used with attributes), it uses mysqli_real_escape_string and a charset of UTF-8 when communicating with the database.  In general, checking for illegal characters is a bad approach, as it leads to cleverer exploits. 

    It is conceivable that you are using an older version that has a bug in it.  You should update to the latest to pick up all the security fixes.  The most recent change was to always use UTF-8, which is required for mysqli_real_escape_string to work consistently (other character sets are also safe but some are unsafe).  Before that was the switch to casting to int and mysqli_real_escape_string (I forget which was more recent--both are really old). 


  2. 13 minutes ago, raiwa said:

    This is not related to PWA.

    Are you sure?  Isn't there a PWA customer data module that runs on the regular create account page to set the is_guest to false? 

    There are no calls to tep_guarantee_subarray in core, so it would have to be an App.  The message is basically saying that tep_guarantee_subarray should be replaced with Guarantor::guarantee_subarray instead. 

    I agree that turning display_errors to 0 would get rid of

    11 hours ago, Kaiser0145 said:

    Warning: session_regenerate_id(): Cannot regenerate session id - headers already sent in catalog/includes/functions/sessions.php on line 160

    Warning: Cannot modify header information - headers already sent by (output started at catalog/includes/system/versioned/1.0.7.other/1.0.7.12/guarantor.php:43) in includes/functions/general.php on line 36

    That is the obvious short term solution to it breaking the store.  Production stores should not have display_errors on in general. 


  3. 25 minutes ago, raiwa said:

    To convert it to all upper case just replace "RemoveShouting" with "strtoupper".

    I don't think that's what he wants.  I read it as wanting REMOVE SHOUTING to become Remove Shouting.  What is often called Title Cased.  So he may want ucwords to wrap either RemoveShouting or strtolower. 

            if (isset($customer_details['company']) && MODULE_STORE_SWCLEANER_CLEAN_COMPANY == 'True') {
              $customer_details['company'] = ucwords(RemoveShouting($customer_details['company'], 'company'));
            }

    I.e. his problem is "INTERNATIONAL BUSINESS MACHINES" is becoming "International business machines" when he wants "International Business Machines".  I guess he's all right with IBM becoming Ibm. 


  4.  

    18 minutes ago, LeeFoster said:
    
    $_SESSION['admin'] = [
      'id' => $check['id'],
      'username' => $check['user_name'],
      'user_group_id' => $check['user_group_id'],
      'default_page' => $check['default_page'],
    ];

     

    I would try doing it immediately after that code. 

    You also might change

    echo '<script>
    window.location.replace("'.DIR_WS_HTTPS_ADMIN.'/index.php");
    </script>';

     


  5. I'm assuming that you'd use this for people who aren't allowed to view the index page. 

    If you want people who can view the index page to start with a different page, you'd probably need to use one of the other solutions.  Or add another session variable for "just logged in" that you would unset just before redirecting. 


  6. Even without moving all the logic, you could use the same logic for finding the user_group_id as you do later. 

    Another option would be to create a page called redirect.php and always redirect to that -- your info pages example proves that works.  Then, on that page, redirect to the correct page by "user_group_id". 

    For that matter, a hook on index.injectAppTop would allow you to redirect after going to the index page. 


  7.               if (isset($_SESSION['redirect_origin'])) {
                    $page = $redirect_origin['page'];
                    $get_string = http_build_query($redirect_origin['get']);
    
                    unset($_SESSION['redirect_origin']);
    
                    tep_redirect(tep_href_link($page, $get_string));
                  } else {
                    tep_redirect(tep_href_link('index.php'));
                  }

    This code runs before the

    $OSCOM_Hooks->call('login', 'processAction');

    I.e. the hook only runs when log in fails. 

    I think that you would be better off hooking

      $OSCOM_Hooks->call('login', 'preAction');

    and setting the redirect_origin if it is not already set when the action is 'process'. 

    Alternately, duplicate the entire process action in the preAction hook and unset the action, which would let you make more changes. 

    Note that you may find that you get more help within the Phoenix Club. 


  8. 6 hours ago, Mikepo said:

    Fatal error: require(): Failed opening required '/opt/lampp/htdocs/phoenix/templates/default/includes/ext/modules/content/reviews/write_pwa.php' (include_path='.:/opt/lampp/lib/php') in /opt/lampp/htdocs/phoenix/ext/modules/content/reviews/write_pwa.php on line 100

    TY.  https://github.com/gburton/CE-Phoenix/commit/2214e53a6fce23bd6e3953149b4d0e2d48e1fb82


  9. Well, that warning literally tells you what the problem is.  There is no such directory as includes/languages/french/

    Either create the directory (with the necessary contents), or if the name is wrong, edit the language to point to the right directory.  The place to edit it is admin > Localization > Languages

    If that page won't allow you to edit it, you would have to edit it in something like phpMyAdmin.  It would be the directory column in the languages table. 


  10. 4 hours ago, NicolasW said:

    web/oscommerce/catalog/includes/languages/français

    Delete that.  Or put a // in front to comment it out. 

    You should also restore line 286 to the original. 

    setlocale(LC_NUMERIC, $_system_locale_numeric); // Prevent LC_ALL from setting LC_NUMERIC to a locale with 1,0 float/decimal values instead of 1.0 (see bug #634)

    The way that you have it won't work correctly (bug #634).  But it's not causing your current problem. 


  11. if (!file_exists(DIR_FS_CATALOG . 'templates/default/includes/hooks/shop/siteWide/pwa.php')) {

    I would think that you could instead say

    if (!class_exists('hook_shop_siteWide_pwa')) {

    Then it wouldn't matter where the hook might be, so long as it can be loaded (which is probably what you really want to know).  Or perhaps even

    if (!(($GLOBALS['hook_shop_siteWide_pwa'] ?? null) instanceof hook_shop_siteWide_pwa)) {

    which would check if it has been loaded. 


  12. 6 hours ago, cinolas said:
    
    if (($order->info['total'] - $total_deductions < 0) || ($payment == 'free' && ($order->info['total'] - $total_deductions > 0))) {

     

    This says that if the payment method is free, that the credit covers when the order total is less than the total deductions.  That wouldn't seem to be what you would want.  Perhaps replace that line with

    if (($payment == 'free') && ($order->info['total'] > $total_deductions)) {
      tep_session_unregister('payment');
      $payment = null;
    }
    
    if ($order->info['total'] < $total_deductions) {

    Which instead says, if the the payment is invalid, unset it.  Then continues normally. 

    Note that I would actually expect that check to occur in the module.  If it's not working, that might be a sign of a bigger problem somewhere.  I.e. you might be better off figuring out why it isn't working rather than trying to make this particular circumstance work.  Because there may be another circumstance that you are not checking. 


  13. If you have a .htpasswd file, then you would change the password entirely outside osCommerce.  This may be done in cPanel or through some other, host-specific method.  Ask your host how to change the htpasswd for that directory.  In cPanel, this was called "Password Protect Directories". 

    If you are self-hosting (managing your own server), there are instructions at https://cwiki.apache.org/confluence/display/HTTPD/PasswordBasicAuth but if you are purchasing hosting, you may not have the necessary permissions to do those things in that way. 

    It is also barely possible that you are using an App (contribution) that handled the login.  But the more common way was basic authentication on the directory. 

×