staticrypt not rendering in-place as expected

Question

staticrypt not rendering in-place as expected

bmcminn opened this issue 10 months ago · 2 comments

Attempting to run staticrypt via npx and the resulting file is not rendering in-place as I expect it to

What's happening

I enter the command:

npx staticrypt --short ./deploy/encrypted/index.html --password testing

I'm just attempting to verify the utility works as expected so the short password is fine for now, however the resulting file ends up being written to disk at ./encrypted/index.html instead of ./deploy/encrypted/index.html and this makes zero sense to me.

Digging into the source code this appears to be an unintended pathname collision with the default --directory value "encrypted" assigned in the parseCommandLineArguments() method in helpers.js

What should be happening

I would expect this utility to work in-place and render the target asset where it was previously defined, meaning any fully qualified filepath I pass is mapped implicitly, and the --directory value is a strict output path override that is only used if I provide a value to it.

Justification

I'm using this to encrypt statically generated files for my website that already exist in my ./deploy folder, so I'm not worried about accidentally overwriting my source file as that is not the desired target.

I can see a need for providing a confirmation prompt to the user that this change will be handled in-place and will overwrite the original source file.

Optionally, to avoid any breaking changes with the existing behavior, it would be great to see a --overwrite flag that tells staticrypt to overwrite the files in-place as I expect, and at least this way it's a more obvious and intentional behavior than expecting the user to know they should provide their own --directory argument.

My setup

StatiCrypt version: 3.4.0
Node version: 21.7.1
OS: Ubuntu Linux 22.04

Sample HTML

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Document</title>
</head>
<body>
	Testing Staticrypt
</body>
</html>

Answer 1 · 2024-04-17T15:49:43.000Z

Hi @bmcminn,

Thanks for opening the discussion on that topic. Sorry about the late reply. Are you doing the encryption as part of a build step?

It looks like it's working as intended to me: I want to avoid the default being overwriting the original files so that there's not risk of data loss. Earlier versions of staticrypt would create test_encrypted.html alongside test.html but as you might imagine that didn't scale well to multi-page projects, so we moved to having a whole new directory created.

This makes it easy to encrypt a full directory - all non-html files (css, js, etc) in the input directory are copied to the new directory and should be present in the encrypted/ directory, so in a build script it would be easy to do something like

# encrypt to `encrypted/` with something like `npx staticrypt -r deploy`
rm -rf deploy
mv encrypted deploy

Or if you want to replace all files in place in deploy/encrypted you could do as mentioned here and do

npx staticrypt deploy/encrypted/* -r -d deploy/encrypted

(or maybe cd deploy first)

This makes things a bit heavy when you want to just encrypt one file (your output it in a whole other directory) and I've been meaning to add a -o my_encrypted_file.html option to give more granularity for a while now, but I feel that's not really what you're talking about here.

Answer 2 · 2024-04-17T17:17:30.000Z

For my use-case I'm using a password flag in the frontmatter data of my content files to indicate to my build process that this document should be encrypted with the assigned pass phrase.

In tinkering with this utility I got it working just fine now. However, as you mentioned, the way this utility is designed makes being granular a bit challenging.

The main thing that was unintuitive is the --directory flag is at play at all times and is the defacto output directory. Suppose reading the docs more closely would have made that more apparent, but combined with the fact my test directory was named encrypted the same as --directory defaulting to ./encrypted made it feel like a wierd bug. So this may be a need for clearer documentation or more samples to showcase how the utility is used.

I do think an --overwrite flag could be useful, or perhaps a set of explicit --source and --output path mapping arguments could be a more intuitive pattern.

Additionally this could be trivialized by the JS API suggestion I made in #195