Issues in EcommercePaymentSupportedMethodsProvider.php (master) - Issues in master - sunnysideup/silverstripe-ecommerce - Measure and Improve Code Quality continuously with Scrutinizer

Issues (2002)

Security Analysis not enabled

Cross-Site Scripting

Cross-Site Scripting enables an attacker to inject code into the response of a web-request that is viewed by other users. It can for example be used to bypass access controls, or even to take over other users' accounts.

File Exposure

File Exposure allows an attacker to gain access to local files that he should not be able to access. These files can for example include database credentials, or other configuration files.

File Manipulation

File Manipulation enables an attacker to write custom data to files. This potentially leads to injection of arbitrary code on the server.

Object Injection

Object Injection enables an attacker to inject an object into PHP code, and can lead to arbitrary code execution, file exposure, or file manipulation attacks.

Code Injection

Code Injection enables an attacker to execute arbitrary code on the server.

Response Splitting

Response Splitting can be used to send arbitrary responses.

File Inclusion

File Inclusion enables an attacker to inject custom files into PHP's file loading mechanism, either explicitly passed to include, or for example via PHP's auto-loading mechanism.

Command Injection

Command Injection enables an attacker to inject a shell command that is execute with the privileges of the web-server. This can be used to expose sensitive data, or gain access of your server.

SQL Injection

SQL Injection enables an attacker to execute arbitrary SQL code on your database server gaining access to user data, or manipulating user data.

XPath Injection

XPath Injection enables an attacker to modify the parts of XML document that are read. If that XML document is for example used for authentication, this can lead to further vulnerabilities similar to SQL Injection.

LDAP Injection

LDAP Injection enables an attacker to inject LDAP statements potentially granting permission to run unauthorized queries, or modify content inside the LDAP tree.

Header Injection

Other Vulnerability

This category comprises other attack vectors such as manipulating the PHP runtime, loading custom extensions, freezing the runtime, or similar.

Regex Injection

Regex Injection enables an attacker to execute arbitrary code in your PHP process.

XML Injection

XML Injection enables an attacker to read files on your local filesystem including configuration files, or can be abused to freeze your web-server process.

Variable Injection

Variable Injection enables an attacker to overwrite program variables with custom data, and can lead to further vulnerabilities.

Unfortunately, the security analysis is currently not available for your project. If you are a non-commercial open-source project, please contact support to gain access.

money/EcommercePaymentSupportedMethodsProvider.php (5 issues)

Labels

Severity

Upgrade to new PHP Analysis Engine

These results are based on our legacy PHP analysis, consider migrating to our new PHP analysis engine instead. Learn more

<?php

/**
 * if you want to implement rules around selecting
 * specific payment gateways for specific orders then
 * you need to extend this class and add the following to
 * mysite/_config/config.yml:
 * <code yml>
 *  Injector:
 *    EcommercePaymentSupportedMethodsProvider:
 *      class: MyCustom_EcommercePaymentSupportedMethodsProvider
 * </code>.
 *
 * in PHP you will have something like this:
 * <code php>
 * class MyCustom_EcommercePaymentSupportedMethodsProvider extends EcommercePaymentSupportedMethodsProvider {
 *  //....
 * }
 * </code>
 */
class EcommercePaymentSupportedMethodsProvider extends Object implements EcommercePaymentSupportedMethodsProviderInterface
{
    /**
     * this method returns an associative array of payment methods
     * available for the current order.
     *
     * @return array

     */
    public function SupportedMethods($order = null)
    {
        $hideTestPaymentMethods = false;
        if (Director::isLive()) {
            $hideTestPaymentMethods = true;
        }
        $supportedMethods = EcommerceConfig::get('EcommercePayment', 'supported_methods');
        if (ArrayLib::is_associative($supportedMethods)) {
            if ($hideTestPaymentMethods) {
                if (count($supportedMethods)) {
                    foreach ($supportedMethods as $methodClass => $methodTitle) {
$collection = json_decode($data, true);
if ( ! is_array($collection)) {
    throw new \RuntimeException('$collection must be an array.');
}

foreach ($collection as $item) { /** ... */ }
                        if (is_subclass_of($methodClass, 'EcommercePayment_Test')) {
                            unset($supportedMethods[$methodClass]);
                        }
                    }
                }
            }
        } else {
            user_error('EcommercePayment::$supported_methods() requires an associative array. Right now the supported payments methods are: '.print_r($supportedMethods, 1), E_USER_NOTICE);
        }
        return $supportedMethods;
    }

    public static function assign_payment_gateway($gateway = "")
    {
        user_error("
            This function has not been implemented on this class.
            You can extend this class to allow for a supported method to be set.");
    }
    /**
     * returns the order to use....
     * You can provide one as a param,
     * which basically just checks that it is a real order.
     *
     * @param Order (optional) | Int

     *
     * @return Order

     */
    protected function orderToUse($order = null)
    {
        if ($order && $order instanceof Order) {
            return $order;
        }
        if (intval($order)) {
            return Order::get()->byID(intval($order));
        } else {
            return ShoppingCart::current_order();
        }
        user_error("Can't find an order to use");
function fx() {
    try {
        doSomething();
        return true;
    }
    catch (\Exception $e) {
        return false;
    }

    return false;
}
    }
}


1			<?php
2
3			/**
4			* if you want to implement rules around selecting
5			* specific payment gateways for specific orders then
6			* you need to extend this class and add the following to
7			* mysite/_config/config.yml:
8			* <code yml>
9			* Injector:
10			* EcommercePaymentSupportedMethodsProvider:
11			* class: MyCustom_EcommercePaymentSupportedMethodsProvider
12			* </code>.
13			*
14			* in PHP you will have something like this:
15			* <code php>
16			* class MyCustom_EcommercePaymentSupportedMethodsProvider extends EcommercePaymentSupportedMethodsProvider {
17			* //....
18			* }
19			* </code>
20			*/
21			class EcommercePaymentSupportedMethodsProvider extends Object implements EcommercePaymentSupportedMethodsProviderInterface
22			{
23			/**
24			* this method returns an associative array of payment methods
25			* available for the current order.
26			*
27			* @return array
			0 ignored issues – show Documentation introduced 2016-12-20 03:49 UTC by Report Bug Copy Issue Report Show Similar Issues like this Should the return type not be `array\|integer\|double\|string\|boolean`? This check compares the return type specified in the `@return` annotation of a function or method doc comment with the types returned by the function and raises an issue if they mismatch. Loading history...
28			*/
29			public function SupportedMethods($order = null)
30			{
31			$hideTestPaymentMethods = false;
32			if (Director::isLive()) {
33			$hideTestPaymentMethods = true;
34			}
35			$supportedMethods = EcommerceConfig::get('EcommercePayment', 'supported_methods');
36			if (ArrayLib::is_associative($supportedMethods)) {
37			if ($hideTestPaymentMethods) {
38			if (count($supportedMethods)) {
39			foreach ($supportedMethods as $methodClass => $methodTitle) {
			0 ignored issues – show Bug introduced 2016-12-20 03:49 UTC by Report Bug Copy Issue Report Show Similar Issues like this The expression `$supportedMethods` of type `array\|integer\|double\|string\|boolean` is not guaranteed to be traversable. How about adding an additional type check? There are different options of fixing this problem. If you want to be on the safe side, you can add an additional type-check: $collection = json_decode($data, true); if ( ! is_array($collection)) { throw new \RuntimeException('$collection must be an array.'); } foreach ($collection as $item) { /** ... / } If you are sure that the expression is traversable, you might want to add a doc comment cast* to improve IDE auto-completion and static analysis: /** @var array $collection / $collection = json_decode($data, true); foreach ($collection as $item) { /* .. / } Mark the issue as a false-positive*: Just hover the remove button, in the top-right corner of this issue for more options. Loading history...
40			if (is_subclass_of($methodClass, 'EcommercePayment_Test')) {
41			unset($supportedMethods[$methodClass]);
42			}
43			}
44			}
45			}
46			} else {
47			user_error('EcommercePayment::$supported_methods() requires an associative array. Right now the supported payments methods are: '.print_r($supportedMethods, 1), E_USER_NOTICE);
48			}
49			return $supportedMethods;
50			}
51
52			public static function assign_payment_gateway($gateway = "")
53			{
54			user_error("
55			This function has not been implemented on this class.
56			You can extend this class to allow for a supported method to be set.");
57			}
58			/**
59			* returns the order to use....
60			* You can provide one as a param,
61			* which basically just checks that it is a real order.
62			*
63			* @param Order (optional) \| Int
			0 ignored issues – show Documentation introduced 2016-12-20 03:49 UTC by Report Bug Copy Issue Report Show Similar Issues like this Should the type for parameter `$order` not be `optional\|null`? This check looks for `@param` annotations where the type inferred by our type inference engine differs from the declared type. It makes a suggestion as to what type it considers more descriptive. Most often this is a case of a parameter that can be null in addition to its declared types. Loading history...
64			*
65			* @return Order
			0 ignored issues – show Documentation introduced 2016-12-20 03:49 UTC by Report Bug Copy Issue Report Show Similar Issues like this Should the return type not be `Order\|null`? This check compares the return type specified in the `@return` annotation of a function or method doc comment with the types returned by the function and raises an issue if they mismatch. Loading history...
66			*/
67			protected function orderToUse($order = null)
68			{
69			if ($order && $order instanceof Order) {
70			return $order;
71			}
72			if (intval($order)) {
73			return Order::get()->byID(intval($order));
74			} else {
75			return ShoppingCart::current_order();
76			}
77			user_error("Can't find an order to use");
			0 ignored issues – show Unused Code introduced 2016-12-20 03:49 UTC by Report Bug Copy Issue Report Show Similar Issues like this `user_error('Can\'t find an order to use');` does not seem to be reachable. This check looks for unreachable code. It uses sophisticated control flow analysis techniques to find statements which will never be executed. Unreachable code is most often the result of `return`, `die` or `exit` statements that have been added for debug purposes. function fx() { try { doSomething(); return true; } catch (\Exception $e) { return false; } return false; } In the above example, the last `return false` will never be executed, because a return statement has already been met in every possible execution path. Loading history...
78			}
79			}
80

sunnysideup / silverstripe-ecommerce

Issues (2002)

Security Analysis not enabled

money/EcommercePaymentSupportedMethodsProvider.php (5 issues)

Labels

Severity

Introduced By

Upgrade to new PHP Analysis Engine

Duplication Side-by-Side

Filter issues like