aleahy's avatar

aleahy wrote a reply+100 XP

7h ago

I think what @jsanwo64 was suggesting was that any scripts tags in your vue components could reference the nonce from the window variable.

<template>
  <script :nonce="nonceValue">
    console.log('Safe inline script');
  </script>
</template>

<script setup>
const nonceValue = window. __CSP_NONCE__;
</script>

But that is assuming you have access to whatever is injecting the script.

Have you made sure the issue still exists when you run npm run build? All the vue stuff should be compiled by vite and it should put the nonce on the script for that....

aleahy's avatar

aleahy wrote a reply+100 XP

3d ago

In addition to what you've done, you need to tell Vite to add the nonce in the middleware via Vite::useCspNonce().

This is from the laravel docs:

        Vite::useCspNonce();
 
        return $next($request)->withHeaders([
            'Content-Security-Policy' => "script-src 'nonce-".Vite::cspNonce()."'",
        ]);

For convenience, it's also worth using Spatie's package: https://github.com/spatie/laravel-csp

aleahy's avatar

aleahy wrote a reply+100 XP

3w ago

Call ->setAppends([]) on the instance and it won't go and get the appended properties when hydrating the model for the front end.

aleahy's avatar

aleahy wrote a reply+100 XP

5mos ago

In your composer.json file, you have a collection of packages under "require" and "require-dev". If the packages were only used during dev, and not for production, then you should be putting them in require-dev. In your deploy, you would add the --no-dev flag to the composer install command.

composer install --no-dev --optimize-autoloader

This would avoid installing all the testing packages, etc.

aleahy's avatar

aleahy wrote a reply+100 XP

5mos ago

I don't know your app, so I can't comment on the memory issues, but....

I don't see anything wrong with the first method you show. The classes are clearly listed there if you were to come back to this code after you've completely forgotten how it works. And by using the container to create the classes, you can easily mock each one in tests. And are you dealing with enough data that memory is a concern? Are you able to chunk up the data in any way?

The second way seems to hide everything too much for my liking. If I were new to this project or I had forgotten how it connects, I would have to click around to service providers just to know where everything is and how it works.