Skip to content

Conversation

@tjwiebell
Copy link
Contributor

@tjwiebell tjwiebell commented Jul 10, 2020

Description

Steps -

  1. Run webpagetest for https://develop.pwa-venia.com/ WPT URL - https://www.webpagetest.org/

Expected - New Security should show better results.
Actual - Security score is F.

Related Issue

  • [PWA-680] Webpagetest security score is too low

Acceptance

Verification Stakeholders

Specification

Verification Steps

Passing score on WPT

  1. https://snyk.io/test/website-scanner/?test=200713_3N_d910d2505fdbd03725cba0a30172769c&utm_medium=referral&utm_source=webpagetest&utm_campaign=website-scanner

Since we're introducing a very opinionated CSP rule in this PR, it would also be good to verify this plays nicely with various setups (Both UPWARDs, onboard/backend image opt).

Screenshots / Screen Captures (if appropriate)

Screen Shot 2020-07-13 at 10 34 38 AM

Checklist

  • I have added tests to cover my changes, if necessary.
  • I have updated the documentation accordingly, if necessary.

@PWAStudioBot
Copy link
Contributor

PWAStudioBot commented Jul 10, 2020

Messages
📖

Access a deployed version of this PR here. Make sure to wait for the "pwa-pull-request-deploy" job to complete.

📖 DangerCI Failures related to missing labels/description/linked issues/etc will persist until the next push or next nightly build run (assuming they are fixed).
📖

Associated JIRA tickets: PWA-680.

Generated by 🚫 dangerJS against 680f8f9

@devops-pwa-codebuild
Copy link
Collaborator

devops-pwa-codebuild commented Jul 10, 2020

Performance Test Results

The following fails have been reported by WebpageTest. These numbers indicates a possible performance issue with the PR which requires further manual testing to validate.

https://pr-2548.pwa-venia.com : LH Performance Expected 0.85 Actual 0.51, LH Best Practices Expected 1 Actual 0.92, WPT Cache Expected 90 Actual 83.333333333333
https://pr-2548.pwa-venia.com/venia-tops.html : LH Performance Expected 0.75 Actual 0.34, LH Best Practices Expected 1 Actual 0.92
https://pr-2548.pwa-venia.com/valeria-two-layer-tank.html : LH Performance Expected 0.8 Actual 0.41, LH Accessibility Expected 0.9 Actual 0.89, LH Best Practices Expected 1 Actual 0.92, WPT Cache Expected 65 Actual 52.333333333333

jimbo
jimbo previously approved these changes Jul 10, 2020
x-frame-options:
inline: SAMEORIGIN
x-xss-protection:
inline: '1; mode=block'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be unnecessary. Does WPT expect it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ones included are the five specific headers WPT looks for, dings for each missing one. The browsers that don't support CSP and need this rule we probably don't support anyway, so that's a fair point. We have the option to not include them and defend whatever score WPT decides to give us.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as WPT cares, we can include them.

- Write an interceptor that injects them into the app shell
zetlen
zetlen previously approved these changes Jul 14, 2020
Copy link
Contributor

@zetlen zetlen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, this is a perfect target-plus-interceptor kind of implementation. The future is now.

Possible improvements for later:

  • An UPWARD MergeResolver, so that other definitions could reference these headers, instead of this extension injecting them into Venia
  • Env var definitions for controlling values like max-age, or additional domains for CSP to allow
  • Unit tests, a README for the extension, etc

None are blockers for now. Approved.

"@magento/peregrine": "~6.0.0",
"@magento/pwa-buildpack": "~5.1.1",
"@magento/upward-js": "~4.0.1",
"@magento/upward-security-headers": "*",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This probably should follow the pattern of other deps and be ~0.0.1.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed to this constraint in 27e45b1

Copy link
Contributor

@zetlen zetlen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, thank you for troubleshooting the scaffolding stuff. Your fixes work, but might need future maintenance. I had a couple of ideas to simplify the code--let me know if you want to apply them.

Comment on lines 222 to 231
if (process.env.DEBUG_PROJECT_CREATION) {
prettyLogger.info('Debug: Removing generated tarballs');
const pkgDir = require('pkg-dir');
const monorepoDir = resolve(pkgDir.sync(__dirname), '../../');
const packagesDirectory = resolve(pkgDir.sync(__dirname), '../');
prettyLogger.info(
execa.shellSync('rm -v packages/*/*.tgz', { cwd: monorepoDir })
.stdout
execa.shellSync('find . -name "*.tgz" -delete -print', {
cwd: packagesDirectory
}).stdout
);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why I didn't think of this before, but...what if we just put tarballs in package roots in .gitignore? I just tested it and it worked fine. We could just remove this section in create-project.js entirely. Which would be nice, since now we're not looking for DEBUG_PROJECT_CREATION in two places.

Gitignore additions:

## May temporarily create tarballs during scaffolding debug
packages/*/*.tgz
packages/extensions/*/*.tgz

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got rid of cleanup and added a gitignore rule in 9a0ce84

Comment on lines 135 to 142
const workspaceDir = resolve(__dirname, '../../');
fs.readdirSync(workspaceDir).forEach(packageDir => {
const extensionDir = resolve(workspaceDir, 'extensions');

const packageDirs = [
...fs.readdirSync(workspaceDir),
...fs.readdirSync(extensionDir).map(path => `extensions/${path}`)
];

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works, but I think it would be a little more robust to just ask Yarn what the current packages are.

    // Assume we are in the pwa-studio repo and get its root.
    const monorepoDir = resolve(__dirname, '../../../');

    // The Yarn "workspaces info" command outputs JSON as of v1.22.4.
    // The -s flag suppresses all other non-JSON logging output.
    const yarnWorkspaceInfoCmd = 'yarn -s workspaces info';
    let workspaceInfo = require('child_process').execSync(
        yarnWorkspaceInfoCmd,
        { cwd: monorepoDir }
    );

    let packageDirs;
    try {
        packageDirs = Object.values(JSON.parse(workspaceInfo)).map(
            ({ location }) => resolve(monorepoDir, location)
        );
    } catch (e) {
        // In case Yarn breaks this in the future, throw a more informative
        // error than your typical JSONError.
        throw new Error(
            `Could not parse output of '${yarnWorkspaceInfoCmd}:\n${workspaceInfo}`
        );
    }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love it, made this change in 9a0ce84.

Comment on lines 144 to 146
const packagePath = resolve(workspaceDir, packageDir);
if (!fs.statSync(packagePath).isDirectory()) {
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use the Yarn method in my other comment, you don't need to do this resolve and stat check. packageDirs will contain only absolute-path directories.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much cleaner, implemented in 9a0ce84. This method additionally filters out workspaces without package.json files, so I was able to get rid of that check too.

@tjwiebell tjwiebell added the version: Major This changeset includes incompatible API changes and its release necessitates a Major version bump. label Jul 23, 2020
jimbo
jimbo previously approved these changes Jul 23, 2020
Copy link
Contributor

@jimbo jimbo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me. 🚀

@devpatil7
Copy link
Contributor

@tjwiebell WPT security score looks great on all configs (img_opt - onboard/backend, upward-php/js). Issue I'm seeing with braintree payment module - Infinite loading indicator with below console error -

Refused to frame 'https://assets.braintreegateway.com/' because it violates the following Content Security Policy directive: "child-src 'self'". Note that 'frame-src' was not explicitly set, so 'child-src' is used as a fallback.

@tjwiebell
Copy link
Contributor Author

@tjwiebell WPT security score looks great on all configs (img_opt - onboard/backend, upward-php/js). Issue I'm seeing with braintree payment module - Infinite loading indicator with below console error -

@dpatil-magento - Added an additional rule in 092cd5a that allows iframes to load from that braintree domain. Good catch!

@devpatil7
Copy link
Contributor

QA Approved.

@devpatil7 devpatil7 merged commit 77ab096 into develop Jul 27, 2020
@devpatil7 devpatil7 deleted the tommy/wpt-fix-with-upward branch July 27, 2020 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pkg:extensions pkg:pwa-buildpack pkg:venia-concept pkg:venia-ui version: Major This changeset includes incompatible API changes and its release necessitates a Major version bump.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants