peterbuzzin

Perfect, thank you @bonbec

Looks like the old addons section is still unavailable? Either that or it's well hidden, I can't find it anywhere. I'm tempted to look into V4 but so far I'm getting the impression that the addons are all going to be chargeable? Or am I missing something? Lots of "Price Coming Soon" everywhere.

Hey @MrPhil it's separate as although it needs to be done in order for Login with PayPal to work it would also need to be done in order to use any other "Login with *" module. For simplicity, I'd recommend Option 1 "Relocating the code back to login.php" and then you don't have to remember to always have all "Login with *" set with a lower sort value than "Login Form", it could be any sort value once reverted back to login.php. The code isn't specific to cm_login_form.php and was intended to be available to all login modules, it should not have been moved.

Update Behind the scenes I've been working on this for supercheaphobb to find out what the cause is. After a lot of investigation today we have found the issue and been able to introduce a solution without much change to the code. This issue is present in every install of the Frozen 2.3.4.1 Fork (straight out of the box) and stores will need to make this change in order to use Login with PayPal (now called Connect with PayPal) or any other similar oAuth/token authorisation service such as Login with Google or Facebook. A some point a decision was made to move script from top of login.php and place it amongst the code of includes/modules/content/login/cm_login_form.php. This would have been fine if that code was only intended for the login form but it's intended to be shared amongst and used by any other modules/content/login/***.php modules that need to (i.e. Login with PayPal). This code was originally designed to execute if $login_customer_id was set and more than zero (that was all it needed), but in cm_login_form.php it's been buried within other conditional statements so it will only execute if the traditional login form has been completed and a user/pass match has been found another reason why this code will always fail when using other authentication methods. Full thanks and credit go to supercheaphobb for his sponsorship of this solution. The original script previously located in login.php is //from login.php (originally) if ( is_int($login_customer_id) && ($login_customer_id > 0) ) { if (SESSION_RECREATE == 'True') { tep_session_recreate(); } $customer_info_query = tep_db_query("select c.customers_firstname, c.customers_default_address_id, ab.entry_country_id, ab.entry_zone_id from " . TABLE_CUSTOMERS . " c left join " . TABLE_ADDRESS_BOOK . " ab on (c.customers_id = ab.customers_id and c.customers_default_address_id = ab.address_book_id) where c.customers_id = '" . (int)$login_customer_id . "'"); $customer_info = tep_db_fetch_array($customer_info_query); $customer_id = $login_customer_id; tep_session_register('customer_id'); $customer_default_address_id = $customer_info['customers_default_address_id']; tep_session_register('customer_default_address_id'); $customer_first_name = $customer_info['customers_firstname']; tep_session_register('customer_first_name'); $customer_country_id = $customer_info['entry_country_id']; tep_session_register('customer_country_id'); $customer_zone_id = $customer_info['entry_zone_id']; tep_session_register('customer_zone_id'); tep_db_query("update " . TABLE_CUSTOMERS_INFO . " set customers_info_date_of_last_logon = now(), customers_info_number_of_logons = customers_info_number_of_logons+1, password_reset_key = null, password_reset_date = null where customers_info_id = '" . (int)$customer_id . "'"); // reset session token $sessiontoken = md5(tep_rand() . tep_rand() . tep_rand() . tep_rand()); // restore cart contents $cart->restore_contents(); if (sizeof($navigation->snapshot) > 0) { $origin_href = tep_href_link($navigation->snapshot['page'], tep_array_to_string($navigation->snapshot['get'], array(tep_session_name())), $navigation->snapshot['mode']); $navigation->clear_snapshot(); tep_redirect($origin_href); } tep_redirect(tep_href_link('index.php')); } And has now been moved to includes/modules/content/login/cm_login_form.php at approximately line 61. There are two possible fixes for this and you can choose whichever will best suit your current/future needs. 1: Relocate/move the code back to login.php (but make sure you remove it from cm_login_form.php) or 2: Move the code outside of the conditionals (if statements) that surround it in cm_login_form.php If you choose option 2, you'll need to ensure that you give Login with PayPal a lower sort value in Admin > Modules > Content than the sort value of Login Form as the Login with PayPal code needs to execute before Login Form (as it would have originally before Frozen). So if Login Form has a sort value of 100, give Login with PayPal a sort value of 50. Option 2 Fix below Select the following code on line 61 //from login.php if ( is_int($login_customer_id) && ($login_customer_id > 0) ) { if (SESSION_RECREATE == 'True') { tep_session_recreate(); } $customer_info_query = tep_db_query("select c.customers_firstname, c.customers_default_address_id, ab.entry_country_id, ab.entry_zone_id from " . TABLE_CUSTOMERS . " c left join " . TABLE_ADDRESS_BOOK . " ab on (c.customers_id = ab.customers_id and c.customers_default_address_id = ab.address_book_id) where c.customers_id = '" . (int)$login_customer_id . "'"); $customer_info = tep_db_fetch_array($customer_info_query); $customer_id = $login_customer_id; tep_session_register('customer_id'); $customer_default_address_id = $customer_info['customers_default_address_id']; tep_session_register('customer_default_address_id'); $customer_first_name = $customer_info['customers_firstname']; tep_session_register('customer_first_name'); $customer_country_id = $customer_info['entry_country_id']; tep_session_register('customer_country_id'); $customer_zone_id = $customer_info['entry_zone_id']; tep_session_register('customer_zone_id'); tep_db_query("update " . TABLE_CUSTOMERS_INFO . " set customers_info_date_of_last_logon = now(), customers_info_number_of_logons = customers_info_number_of_logons+1, password_reset_key = null, password_reset_date = null where customers_info_id = '" . (int)$customer_id . "'"); // reset session token $sessiontoken = md5(tep_rand() . tep_rand() . tep_rand() . tep_rand()); // restore cart contents $cart->restore_contents(); if (sizeof($navigation->snapshot) > 0) { $origin_href = tep_href_link($navigation->snapshot['page'], tep_array_to_string($navigation->snapshot['get'], array(tep_session_name())), $navigation->snapshot['mode']); $navigation->clear_snapshot(); tep_redirect($origin_href); } tep_redirect(tep_href_link('index.php')); } Cut and paste it on what will then be approx line 65, the line immediately after the closing/right curly brace/bracket and above the line of code starting with if($error == true){ } //PASTE THE CODE HERE if ($error == true) { $messageStack->add('login', MODULE_CONTENT_LOGIN_TEXT_LOGIN_ERROR); } @burt you might want to patch/fix this, if not in frozen then in the Edge version.

1 down, 1 to go, cool. So I can see you already have the redirect fix added to your code, so unlikely to be that as a next step. Can you confirm the account belonging to the registered paypal address you used to login with has been added to your customers list? If it hasn't then a process elsewhere is failing. If the account has been added, delete it. Then clear your cookies and session data, close the browser, reopen and try again. Osc may be storing navigation history and attempting to redirect you elsewhere or may have partially saved user account information and is missing others which is causing a logged in check to be incomplete.

Ok, So there is an issue that your login with PayPal is 3 years out of date, the newest version is 2017 but I've ran a comparison and the differences are largely the replacement of HTTP_GET_VARS for $_GET and hardcoded db table names . So all indicators at the moment look good, we'll see how it goes. On approx line 123 find: if ( isset($response['email']) ) { $paypal_login_access_token = $response_token['access_token']; tep_session_register('paypal_login_access_token'); $force_login = false; Replace with: if ( isset($response['email']) ) { $paypal_login_access_token = $response_token['access_token']; tep_session_register('paypal_login_access_token'); $force_login = false; if (!isset($response['given_name']) && !isset($response['family_name'])) { //code to extract firstname and lastname from name $name = explode(' ', $response['name']); $response['given_name'] = tep_db_prepare_input($name[0]); $response['family_name'] = tep_db_prepare_input((isset($name[count($name)-1]) ? $name[count($name)-1] : '')); } Try that and we'll see how far we get and what might need doing after

Hi Phil, I suspect this is similar but different. I asked OP to create a separate topic for this instead of posting on my original topic about deprecation. It's all good.

Hey Troy, I know about the issue with the first and last name. Osc looks for indexes given_name and family_name in the response from PayPal. I don't think these are available anymore or not always populated. To overcome this I've had to use a different index i the response to reference called 'name' which contains both the first and last name. So my code looks a little like this if (!isset($response['given_name']) && !isset($response['family_name'])) { //code to extract firstname and lastname from name $name = explode(' ', $response['name']); $response['given_name'] = tep_db_prepare_input($name[0]); $response['family_name'] = tep_db_prepare_input((isset($name[count($name)-1]) ? $name[count($name)-1] : '')); } If you post the contents of your file includes/modules/content/login/cm_paypal_login.php I'll take a look and give you a solution from mine (this is the location and name for the stock OSC 2.3.4.1 so it may differ in your installation but should be similar).

Hi Troy, That's not according to another user, that's me and it was my first post in this topic when I created it (check out page 1) The fixes I listed on the first page makes it become/work with Connect with PayPal. I'm happy to help, but I'd really appreciate it if you'd start a new topic, as your issues are off-topic and specific to your single individual installation from the errors you've listed (invalid client_ID etc) and not the deprecation of Login with PayPal (now Connect with PayPal).

Cool, if that doesn't work would you mind creating a separate topic (where I'll be happy to help) just so this one can stay on topic

Sorry my previous answer was a bit short at the time, I was replying on my mobile whilst sat in traffic. Check in your site files that includes/modules/content/login/templates/paypal_login.php exists. If it does then you have a permission issue if it doesn't then you'll need to upload it.

Nope. You're missing files or permissions issue

osC initialises the variable with $ship_zone_id = 0 on first processing. It then queries the DB to find the country provided by PayPal in the shipping address contained in PayPal If the country is present in osC it then queries again to see if the region (contained in $ship_zone) provided by PayPal exists in the osC DB as a zone name (Alabama for example) or zone code (AL), if it does then $ship_zone_id is given the ID (1) contained in osC DB So later on when it gets to approx 213 it looks to see if $ship_zone_id is greater than zero (the result of whether a matching region was returned). If it's greater than zero then it's applied to $sql_data_array['entry_zone_id'] If it's not then instead of storing the ID against entry_zone_id (because it doesn't exist) it saves the name/text of the region provided by PayPal in entry_state. It's the exact same process/logic as create_account.php, it doesn't save the text value of the state/region because the state ID is already present in table zones.

It's not possible to get a phone number from PayPal any longer. Only option would be to ask the customer to enter the number after login. You'd need to code a secondary page after login with PayPal that just has one field asking for the telephone number and if you wanted to make it compulsory, code it so that they cannot proceed past that page without entering a number.

You could, but you'd need to do that on every instance of echo $_POST or echo $_GET. This was partly why I couldn't understand why the decision was made to change $HTTP_POST_VARS/$HTTP_GET_VARS to $_POST/$_GET (unless previously global functionality has been compensated for also [and that's global in terms of applying the process before utilisation of variables and not super global]) aside from a bit of a waste of effort. Anyway, as mentioned this might be better in a separate thread/topic so this one can stay on topic.

I know I said about creating a separate thread (and I hope you still do) but until then I've just thought of something that could be a vulnerability with regards to Frozen and the removal of $HTTP_POST_VARS and $HTTP_GET_VARS, what is being done to escape the $_POST and $_GET variables instead? Without escaping them someone could easily perform Cross-Site Scripting (XSS) client side attacks/injections on form fields. The $HTTP_POST_VARS and $HTTP_GET_VARS were a creation of do_magic_quotes_gpc() function in compatibility.php and even if they referred to the now deprecated PHP variables names offered basic protection against XSS. Is there compensation for this by the use of a similar function to loop through all $_POST and $_GET arrays in frozen before they're used? If not, then on forms where the original input is outputted back on the page (as an example) on submission if a naked echo $_GET['keyname'] is being used instead of $HTTP_GET_VAR['keyname'] this could/will have disastrous outcomes! As an example, if you had <textarea><?php echo $_GET['keyname'];?></textarea> that could easily be turned into and output like.... <textarea>{start point of injection}</textarea> <script>naughty javascript inserted here</script>Enter your Card details:<input type="text" required></input> <textarea>{end point of injection}</textarea>

Unfortunately I think HPDL isn't keeping up-to-date with PayPal patches. The changes and feature deprecations at PayPal have been publicised for sometime now. With regards to Frozen, I'm not aware of the point when it became a fork. osCommerce v2.3.4.1 as downloaded from the homepage doesn't come with the PayPal App. It has PayPal modules which are active at the time of installation but not the App. The App adds additional includes/apps and includes/hooks directories, if you have these present then you're halfway there. Hop you don't mind me asking, I'm happy to continue to help/advise but I'm just thinking this thread could go very off topic and I don't want the fixes to get lost amongst it all. Would you mind creating a new thread and tagging me in it and we can carry on chatting about it there if you like.

Hey @Smoky Barnable, Think I can help you with this too. The Express button and the Login button are two different beasts. As always please backup before making any changes and test all changes after. Express Button The Express button specifics vary depending on how you have it configured, whether it's dynamic or static. If it's static then it is an image that's loaded from paypalobjects.com but is done in the old fashioned way of <img src="https://www.paypalobjects.com/...."> so not much can be done about that other than to save the image and then upload it to your server so it's served locally which will speed up display. You'll need to change the definition for this URL found in includes/apps/paypal/languages/english/modules/EC/EC.php on line 22 approx. All of these changes are based on 5.018 of the stock osC PayPal App (not Frozen etc) From: module_ec_button_url = https://www.paypalobjects.com/webstatic/en_US/i/buttons/checkout-logo-medium.png To (as an example): module_ec_button_url = https://www.mydomainname.com/images/buttons/checkout-logo-medium.png However any auto-updates applied in the future will revert it back to stock. IF it's being loaded dynamically then it could be because it's trying to render before the page has fully loaded all resources and this is the same problem I've found with the Login button also suffers from. For the next part to work, jQuery must be called on the page before the output of this script in paypal_express.php In includes/modules/payment/paypal_express.php approx line 220 find: $string .= <<<EOD <span id="ppECButton"></span> <script> paypal.Button.render({ env: '{$server}', style: { size: '${button_size}', color: '${button_color}', shape: '${button_shape}' }, payment: function(resolve, reject) { paypal.request.post('${ppecset_url}') .then(function(data) { if ((data.token !== undefined) && (data.token.length > 0)) { resolve(data.token); } else { window.location = '${ppecerror_url}'; } }) .catch(function(err) { reject(err); window.location = '${ppecerror_url}'; }); }, onAuthorize: function(data, actions) { return actions.redirect(); }, onCancel: function(data, actions) { return actions.redirect(); } }, '#ppECButton'); </script> EOD; And replace with: $string .= <<<EOD <span id="ppECButton"></span> <script> $( document ).ready(function() { paypal.Button.render({ env: '{$server}', style: { size: '${button_size}', color: '${button_color}', shape: '${button_shape}' }, payment: function(resolve, reject) { paypal.request.post('${ppecset_url}') .then(function(data) { if ((data.token !== undefined) && (data.token.length > 0)) { resolve(data.token); } else { window.location = '${ppecerror_url}'; } }) .catch(function(err) { reject(err); window.location = '${ppecerror_url}'; }); }, onAuthorize: function(data, actions) { return actions.redirect(); }, onCancel: function(data, actions) { return actions.redirect(); } }, '#ppECButton'); }); </script> EOD; PayPal Login THE CHANGES BELOW ARE ONLY FOR THOSE WHO HAVE SWAPPED OVER TO https://www.paypalobjects.com/js/external/connect/api.js LIKE SMOKY HAS (SEE OTHER POST REGARDING PAYPAL LOGIN UPDATE In includes/modules/content/login/templates/paypal_login.php find: <script type="text/javascript" src="https://www.paypalobjects.com/js/external/connect/api.js"></script> <script type="text/javascript"> paypal.use( ["login"], function(login) { login.render ({ <?php if ( OSCOM_APP_PAYPAL_LOGIN_STATUS == '0' ) { echo ' "authend": "sandbox",'; } if ( OSCOM_APP_PAYPAL_LOGIN_THEME == 'Neutral' ) { echo ' "theme": "neutral",'; } ?> "responseType" : "code id_Token", "locale": "<?php echo $cm_paypal_login->_app->getDef('module_login_language_locale'); ?>", "appid": "<?php echo (OSCOM_APP_PAYPAL_LOGIN_STATUS == '1') ? OSCOM_APP_PAYPAL_LOGIN_LIVE_CLIENT_ID : OSCOM_APP_PAYPAL_LOGIN_SANDBOX_CLIENT_ID; ?>", "scopes": "<?php echo implode(' ', $use_scopes); ?>", "buttonType" : "CWP", "buttonShape" : "rectangle", "buttonSize" : "md", "fullPage" : "false", "containerid": "PayPalLoginButton", "returnurl": "<?php echo str_replace('&amp;', '&', tep_href_link(FILENAME_LOGIN, 'action=paypal_login', 'SSL', false)); ?>" }); }); </script> And replace with: <script type="text/javascript" src="https://www.paypalobjects.com/js/external/connect/api.js"></script> <script type="text/javascript"> $( document ).ready(function() { paypal.use( ["login"], function(login) { login.render ({ <?php if ( OSCOM_APP_PAYPAL_LOGIN_STATUS == '0' ) { echo ' "authend": "sandbox",'; } if ( OSCOM_APP_PAYPAL_LOGIN_THEME == 'Neutral' ) { echo ' "theme": "neutral",'; } ?> "responseType" : "code id_Token", "locale": "<?php echo $cm_paypal_login->_app->getDef('module_login_language_locale'); ?>", "appid": "<?php echo (OSCOM_APP_PAYPAL_LOGIN_STATUS == '1') ? OSCOM_APP_PAYPAL_LOGIN_LIVE_CLIENT_ID : OSCOM_APP_PAYPAL_LOGIN_SANDBOX_CLIENT_ID; ?>", "scopes": "<?php echo implode(' ', $use_scopes); ?>", "buttonType" : "CWP", "buttonShape" : "rectangle", "buttonSize" : "md", "fullPage" : "false", "containerid": "PayPalLoginButton", "returnurl": "<?php echo str_replace('&amp;', '&', tep_href_link(FILENAME_LOGIN, 'action=paypal_login', 'SSL', false)); ?>" }); }); }); </script> Again, any changes made to the above files will be overwritten if the PayPal auto-update button is used at anypoint in the future.

@pete2007 it sure is (but don't tell burt I told you this or he'll get all "Stack Overflow" on me!!). Again, anyone else reading this, this is method is specific for pete2007's installation which doesn't make use of Header Tags modules nor $oscTemplate->getBlocks('footer_scripts'); and everything is hardcoded in template_bottom.php In ext/jquery/main.js find: /* BOF Prevent multiple form submissions from multiple clicks on checkout_confirmation.php */ if($('form[name=checkout_confirmation]').length > 0){ $('form[name=checkout_confirmation]').submit(function(){ Replace with: /* BOF Prevent multiple form submissions from multiple clicks on checkout_confirmation.php and contact_us.php */ if($('form[name=checkout_confirmation], form[name=contact_us]').length > 0){ $('form[name=checkout_confirmation], form[name=contact_us]').submit(function(){ And then just for the sake of completeness find: /* EOF Prevent multiple form submissions from multiple clicks */ And replace with: /* EOF Prevent multiple form submissions from multiple clicks on checkout_confirmation.php and contact_us.php */ The only caveat is that it will only display one message i.e. "Loading please wait", might have been nicer to have "Sending please wait" for the contact form. But if you want you could change it to just "Please wait" which would apply equally to both forms nicely.

@MrPhil The paypal app code is hosted on oscommerce.com and most likely maintained by HPDL. From the following URL https://apps.oscommerce.com/index.php?Download&paypal&app&2_300&5_018&update for example will download the latest version in a zip file. So unless HPDL updates the codebase to refect changes it will overwrite when pressing the auto-update button. But it's easy enough to change the auto-update URL so it points to a different repository that contains non-breaking/compatible archives which will then effectively cut off HPDL updates but as long as you mirror any updates with code amended for Frozen. (I'm considering doing the same as I've customised the PP modules heavily and if one of my clients hit the update button it would be lost so I've hidden it for now) What were the reasons for removing them, why is it a bad thing? Seems like a lot of effort to remove something and replace it with something which is basically the same thing. There's nothing bad about replacing them other than you'll lose the auto-escaping feature, and any existing modules that would have been compatible would need to be updated (swapping out $HTTP_POST_VARS for $_POST for example) for the sake of continuity. Time could be better spent elsewhere IMO.

Hi @burt I'm well aware of it but the request wasn't to create a module and I don't have time to do that for free at the moment either. Also it would not have worked in the OP's case, jQuery's script src is hardcoded into the OP's template_bottom.php file (sent via PM) and after the output of $oscTemplate->getBlocks('footer_scripts'); which is empty. So if it had been pulled via footer_scripts it would not have worked and console would have shown the error $ is not defined.

@zefeena mcmannehan is partly correct, . You haven't said the specific WorldPay module you're using, so I'm going to use a little guesswork here but I've done my fair share of WorldPay integrations so should be ok and I'll assume the stock WorldPay/rbsworldpay module that comes with osC v2.3.4 bootstrap as per your sig. It could be one of the following: The customer is not being forwarded to checkout_process.php after payment and after being taken to hosted_callback.php from WorldPay Or there is an issue with your checkout_process.php file which isn't triggering the before_process() function in includes/modules/payment/rbsworldpay_hosted.php (or the issue could be in this file) So pinpointing the issue should be the first step and the following will provide me with some clues. Are some baskets being emptied and some not OR are all baskets not being emptied? Are order confirmation emails being sent to yourself and the customer when payment is successful? If you're happy to do so, please attach the following files and I'll take a look: /ext/modules/payment/rbsworldpay/hosted_callback.php /includes/modules/payment/rbsworldpay_hosted.php /checkout_process.php

@pete2007 you're welcome

Hi @pete2007 Thank you for sending the files in a PM. I've placed my response here so that if anyone else is in the same situation as you then they can see the solution also. Your store setup: Doesn't use or load jQuery UI jQuery and javascript is executed from includes/template_bottom.php and not in the <head> tag. Because of this, the script cannot be added directly to checkout_confirmation.php because jQuery loads after the contents of this page. Your site makes good use of a ext/jquery/main.js file instead of inline/on-page Javascript so we'll use this to house the new script. Your store submit button doesn't have any classes applied so no need to copy them to the new dynamic button before hiding the submit button once clicked. Please backup the ext/jquery/main.js file before making changes and be sure to test the checkout_confirmation.php page after making the changes as I've not been able to test this. You may also need to clear your temporary internet files/cache if your browser doesn't detect the additional code to the file immediately. In ext/jquery/main.js Go to the very bottom of the file after the closing }); and press return twice to create some spacing. Add the following, save and upload. /* BOF Prevent multiple form submissions from multiple clicks on checkout_confirmation.php */ if($('form[name=checkout_confirmation]').length > 0){ $('form[name=checkout_confirmation]').submit(function(){ var btnLoadingTxt = 'Loading Please Wait'; var confirmationForm = $(this); confirmationForm.find('button[type=submit]').each(function (index) { $(this).clone(false).attr('id', 'disabledBtn').prop('disabled', true).text(btnLoadingTxt).insertBefore($(this)); $(this).hide(); confirmationForm.prepend($(this)); }); }); } /* EOF Prevent multiple form submissions from multiple clicks */ Because we can't add this code directly to the checkout_confirmation.php page if left as it was it would attempt to execute on every page load. It would only work on the checkout_confirmation.php page but there's still no point taking extra resources to attempt to execute when not needed so I've added code to check if the confirmation form is present before execution.

Hi Phil, I'm not familiar with Frozen/patches but I'm sure it's/they're not too different. First question: can PayPal in Frozen auto-update like it can in the default/stock osC PayPal App? If it can then the change is likely to be overwritten at some point. If there's updates available it would be a good idea to update first and then apply the changes for the fix and then apply them to the repository of where the codebase lives for auto-update. I'm happy to look over this and use my code comparison tools. Again not familiar with Frozen but generally with osC it's best not to use naked $_POST/$_GET in code (as you're probably aware already) and as long as application_top.php is loaded before the PayPal files then those variables will available via $HTTP_POST_VARS and $HTTP_GET_VARS as declared by includes/functions/compatibility.php which also escapes special characters if need be.