Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Receiving errors when trying to install Enlightn on a project that has Larastan v2 installed.

As I was trying to figure this out I opened 2 issues that can be referenced here: https://github.com/enlightn/enlightn/issues/103 https://github.com/nunomaduro/larastan/issues/1165

Describe the solution you'd like A clear and concise description of what you want to happen.

Would be nice to have updated support/a new verision of Enlightn for Larastan v2.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Not sure if there are any other solutions.

Additional context Add any other context or screenshots about the feature request here.

Versions

• PHP version: 8
• Laravel version: 8
• Enlightn version: latest

Description

Getting error "Your application contains global middleware that is not currently being used. [...] Your unused middleware include: [TrustHosts]".

Test assumes that you should not use TrustHosts without also using TrustedProxy. TrustHosts middleware calls the Request::setTrustedHosts. By looking into Symfony's Request class documentation I understand that it is related with Host header and not with X-Forwarded-Host header mentioned in the enlightn docs.

Expected behavior:

Test to pass

Actual behavior:

Test fails

It does seem that this causes Enlightn\Enlightn\Tests\Analyzers\Security\LicenseAnalyzerTest::confirms_enlightn_uses_dependencies_with_safe_licenses to fail as nette/schema and nette/utils have GLP-2.0-only and GPL-3.0-only in their respective license chains.

This looks to have been fixed in #69, though.

nette/schema                          v1.2.2     BSD-3-Clause, GPL-2.0-only, GPL-3.0-only
nette/utils                           v3.2.5     BSD-3-Clause, GPL-2.0-only, GPL-3.0-only

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 9.x.

Before merging, you need to:

• Checkout the l9-compatibility branch
• Review all comments for additional changes
• Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

Versions

• PHP version: 8.1.3
• Laravel version: 9.15
• Enlightn version: ^2.1
• Enlightn Pro version (if applicable): ^2.0

Description

When I try to install the pro version on my project. I faced the issue like in the above image.

Steps to Reproduce

Just try to install the pro version from here

Is your feature request related to a problem? Please describe. I'd like to run enlightn in the CI to check every time if there are problems occurring. Currently the CI passes even if there are problems.

Describe the solution you'd like It would be nice if there is a flag (something like --fail) that the status code returned is not "okay" and the CI will fail this step. Some Analyzers could probably be ignored (depends on the use case) so I would also suggest an config entry where you can add Analyzers which will show errors but will not mark the analytics as failed. (something like "ignoreFailing")

If wished for, I would make a PR in some days (probably on the weekend).

Is your feature request related to a problem? Please describe. its a bit frustrating when i cant see the hidden lines

Describe the solution you'd like the max visible lines are 5 & so having away to get around that would be very helpful

Describe alternatives you've considered php artisan enlightn | more, did nothing

Additional context

The SensioLabs security checker is deprecated and the web service will stop running at the end of this month (Jan 2021) 😱.

We have a couple of options:

1. Use the Local PHP Security Checker which is ironically not in PHP. Usage of this can be an issue. It can't be pulled in by Composer. Perhaps we can host this on our own, not sure yet.

2. Build our own checker that reads the Security Advisories Database and possibly open source it.

We have until the end of the month to figure this out. If anyone has any ideas, please comment here. PRs much appreciated.

/cc @m1guelpf

Versions

• PHP version: 7.4.8
• Laravel version: 7.30.0
• Enlightn version: 1.0
• Enlightn Pro version (if applicable): n/a

Description

During the run of the command php artisan enlightn we got the next result:

We checked logs, but there no issues.

Steps to Reproduce

Install the library via composer require --dev enlightn/enlightn. Run the command php artisan enlightn.

Expected behavior:

All 60 checks are passed.

Actual behavior:

Command exited after 6th check.

Hi,

• PHP version:7.4.26
• Laravel version:8.83.19
• Enlightn version: 2.1.0
• Enlightn Pro version (if applicable): -

Description

When I run enlightn, for composer.json check it shows failed.

  Your application's composer.json file is valid. Failed
Your application's composer.json file is not valid. Run the composer validate command to view more details.

If I check it with "composer validate" command it shows composer.json is valid.

Is it false positive or am I missing something?

Versions

• PHP version: 8.1
• Laravel version: 9.2
• Enlightn version: 2.1
• Enlightn Pro version (if applicable): 2.1

Description

When I run

php -d memory_limit=10G artisan enlightn --ci

Several analyzers report issues: +----------------+-------------+-------------+-----------+-----------+ | Status | Performance | Reliability | Security | Total | +----------------+-------------+-------------+-----------+-----------+ | Passed | 7 (58%) | 22 (71%) | 31 (86%) | 60 (76%) | | Failed | 1 (8%) | 4 (13%) | 4 (11%) | 9 (11%) | | Not Applicable | 4 (33%) | 5 (16%) | 1 (3%) | 10 (13%) | | Error | 0 (0%) | 0 (0%) | 0 (0%) | 0 (0%) | +----------------+-------------+-------------+-----------+-----------+

However, when I run

php -d memory_limit=10G artisan enlightn:baseline --ci

The progress bar starts moving very slowly, and then after 3/79, it jumps to complete immediately. Upon checking the 'ignore_errors' array in enlightn.php however, only one analyzer is listed

'ignore_errors' => [
        Enlightn\EnlightnPro\Analyzers\Security\DebugStatementAnalyzer::class => [
            [
                'path' => 'app/OURAPP/TestHelpers/CurrentApiTestTrait.php', 'details' => 'Function print_r called.'
            ]
        ]
    ],

Steps to Reproduce

1. run php -d memory_limit=10G artisan enlightn --ci
2. Observe and take a note of the problems reported
3. run php -d memory_limit=10G artisan enlightn:baseline --ci
4. Notice that the ignore_errors array is not populated with reported analyzers listed in step 1

Expected behavior:

'ignore_errors' array should have the same analyzers which reported problems in first run listed

Actual behavior:

'ignore_errors' array only has one analyzer listed
'ignore_errors' => [
        Enlightn\EnlightnPro\Analyzers\Security\DebugStatementAnalyzer::class => [
            [
                'path' => 'app/OURAPP/TestHelpers/CurrentApiTestTrait.php', 'details' => 'Function print_r called.'
            ]
        ]
    ],

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

The feature request is not necessarily related to a problem but it will definitely prevent problems.

The solution I am proposing is to add one or more analysers that can check if certain methods are used in the 'AppServiceProvider' like:

• Model::preventLazyLoading(); to prevent N+1 problems.
• Model::preventAccessingMissingAttributes(); to protect against partially hydrated models
• Model::preventSilentlyDiscardingAttributes(); to encourage model strictness

More in depth information about those methods: https://planetscale.com/blog/laravels-safety-mechanisms. It requires at least Laravel 9.35.0 though.

If interested I can look at making a PR for this.

TODO

• [x] Check if the app uses the Inertia middleware and if its overriding the default Exception render method
• [x] Write tests

Summary

I want to check if the app uses the "Inertia way" of overriding the Laravel default error pages. I noticed that when overriding the default render method the result of checking the actual render method is different. This code:

$handler = new ReflectionClass(app()->make(\App\Exceptions\Handler::class));
$className = $handler->getMethod('render')->getDeclaringClass()->getName();
dd($className);

Result when overriding the default render method: App\Exceptions\Handler

Result when not overriding the default render method: Illuminate\Foundation\Exceptions\Handler

So I decided to check if the actual render method is overridden. I’m not sure if this will be enough or that we also want/can check the content of the render method.

Is your feature request related to a problem? Please describe. Currently the reliability check 22: "Your application defines custom error page views" fails. I guess it fails because I use "the Inertia way" of showing custom error pages. When I go to a random page in my application the custom error page is shown.

Describe the solution you'd like Determine if the app is using Inertia and check if custom error pages are rendered in the Handler.php as described in the Inertia documentation.

Describe alternatives you've considered Disabling the error message.

Additional context If possible I want to create a PR myself but I don't know (yet) if that's possible. As stated in the Inertia documentation mentioned earlier the custom error pages are rendered in the Handler.php file:

    public function render($request, Throwable $e)
    {
        /** @var \Illuminate\Http\Response $response */
        $response = parent::render($request, $e);

        if (!app()->environment(['local', 'testing']) && in_array($response->status(), [500, 503, 404, 403])) {
            return Inertia::render('Error', ['status' => $response->status()])
                ->toResponse($request)
                ->setStatusCode($response->status());
        } else if ($response->status() === 419) {
            return back()->with([
                'message' => 'The page expired, please try again.',
            ]);
        }

        return $response;
    }

I guess the check is looking for custom error pages like described here in the Laravel documentation. But that's not the most optimal way when using Inertia.

Please let me know if I can help with any solution, if the feature request will be accepted 👍🏼

Versions

• PHP version: v8.1
• Laravel version: v9.20
• Enlightn version: v2.1
• Enlightn Pro version (if applicable): v2.2

Description

When trigger enlightn checks from Windows I am receiving an 'Unable to launch a new process' warning triggered at line 349 of symfony's Process.php

Steps to Reproduce

Run most checks, including all that use phpstan

e.g. : php artisan enlightn Enlightn\Enlightn\Analyzers\Reliability\InvalidMethodCallAnalyzer -v

Expected behavior:

Enlightn runs

Actual behavior:

Additional Information

This code base allows running on Linux environments without issue. Via windows I am able to execute the project fully.

I am also able to run (via windows) phpstan directly.

Versions

• PHP version: 8.0.*
• Laravel version: 5.8.0.0
• Enlightn version:
• Enlightn Pro version (if applicable): 1.16.0

Description

I have just installed MailCoach from Spatie and I have this error when running enlightn:

Check 66/110: An appropriate timeout and retry after is set for queues. Failed
The queue timeout value must be at least several seconds shorter than the retry after configuration value. Your mailcoach-redis queue connection's retry after value is set at 660 seconds while your timeout value is set at 3600 seconds. This can cause problems such as your jobs may be processed twice or the queue worker may crash.
At config/queue.php: line(s): 64.
Documentation URL: https://www.laravel-enl

So is a very good point, I have alerted Spatie about their default configuration https://github.com/spatie/laravel-mailcoach/discussions/853

But if I set the timeout to 11 * 60 -3, I have now a new error :

The queue timeout value must be at least several seconds shorter than the retry after configuration value. Your redis queue connection's retry after value is set at 90 seconds while your timeout value is set at 657 seconds. This can cause problems such as your jobs may be processed twice or the queue worker may crash.
At config/queue.php, line 64.

I think the 90 comes from the default redis connection retry after parameter which is not used at all in horizon defaults array in mailcoach supervisors.

Steps to Reproduce

Use this horizon configuration:

    'defaults' => [
        'supervisor-default' => [
            'connection' => 'redis',
            'queue' => ['default'],
            'balance' => 'simple',
            'memory' => 100,
            'tries' => 3,
            'nice' => 0,
        ],
        'supervisor-browser' => [
            'connection' => 'redis',
            'queue' => ['browser'],
            'balance' => 'simple',
            'memory' => 192,
            'tries' => 3,
            'nice' => 0,
        ],
        'mailcoach-general' => [
            'connection' => 'mailcoach-redis',
            'queue' => ['mailcoach', 'mailcoach-feedback', 'send-mail', 'send-automation-mail'],
            'balance' => 'auto',
            'memory' => 100,
            'processes' => 10,
            'tries' => 2,
            'timeout' => 11 * 60 - 3,
        ],
        'mailcoach-heavy' => [
            'connection' => 'mailcoach-redis',
            'queue' => ['send-campaign'],
            'balance' => 'auto',
            'memory' => 100,
            'processes' => 3,
            'tries' => 1,
            'timeout' => 11 * 60 - 3,
        ],
    ],

    'environments' => [
        'production' => [
        ],

        'staging' => [
        ],

        'local' => [
        ],

        'CI' => [
        ],
    ],

and use this queue configuration:

    'connections' => [
        'sync' => [
            'driver' => 'sync',
        ],
...
        'mailcoach-redis' => [
            'driver' => 'redis',
            'connection' => 'mailcoach',
            'queue' => 'mailcoach',
            'retry_after' => 11 * 60,
            'block_for' => null,
        ],

        'redis' => [
            'driver' => 'redis',
            'connection' => 'default',
            'queue' => env('REDIS_QUEUE', 'default'),
            'retry_after' => 90,
            'block_for' => null,
        ],
    ],

Expected behavior:

Test pass

Actual behavior:

Test does not pass because I cannot see in src/Analyzers/Reliability/QueueTimeoutAnalyzer.php in method getTimeoutAndRetryAfter(array $config) a mapping between superivisor and connections.

It only get all supervisors and all connections:

            data_get(config('horizon.defaults', []), '*.timeout'),

Additional Information

I have disable this check for the moment but it is a very good check I would like to keep running ;-)