Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

abstract filesystem calls #24

Open
KJLJon opened this issue Dec 12, 2017 · 2 comments
Open

abstract filesystem calls #24

KJLJon opened this issue Dec 12, 2017 · 2 comments

Comments

@KJLJon
Copy link
Contributor

KJLJon commented Dec 12, 2017

I think the file system calls in Vault should be abstracted into an interface so the vault could be stored in other locations and someone could leverage packages like flysystem.

Of course default it with the file system for ease of use.

namespace starekrow\lockbox;

interface FileSystemInterface {
    /**
     * gets the content of a file
     * @param string $file
     * @return string
     */
    public function get($file);

    /**
     * puts content into a file
     * @param string $file
     * @param string $content
     * @return bool if it was successful
     */
    public function put($file, $content);

    /**
     * checks if the file exists
     * @param string $file
     * @return bool if it exists
     */
    public function has($file);
}
namespace starekrow\lockbox;

class LocalFileSystem implements FileSystemInterface {
    /**
     * @inheritdoc
     */
    public function get($file)
    {
        return @file_get_contents($file);
    }

    /**
     * @inheritdoc
     */
    public function put($file, $content)
    {
        return @file_put_contents($file, $content);
    }

    /**
     * @inheritdoc
     */
    public function has($file)
    {
        return file_exists($file);
    }
}
@starekrow
Copy link
Owner

starekrow commented Dec 12, 2017

Interesting; I’d be happy to see a PR along these lines. FYI, the main considerations that went into the design of the CryptoCore:

  1. Semantic ease of use: Being able to call Crypto::hash(...) without any preliminaries is important.
  2. see point 1.

@starekrow
Copy link
Owner

starekrow commented Dec 13, 2017

Upon reflection, feel free to ignore that comment. It made a lot of sense for Crypto to be set up as an accessible, independent component that was self-configuring. OTOH, the FileSystemInterface could easily be managed by and/or through the Vault class, so adding a bit of required boilerplate to use it is really a non-issue.

I assume you were thinking along the lines of adding a $filesys argument to the Vault constructor that, if left null, would default to LocalFileSystem (or perhaps inspect the given path for "http:" etc).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants