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

Feature Request: Server-Assisted External Configuration Mode #91

Open
chasemaier opened this issue Aug 29, 2020 · 1 comment
Open

Feature Request: Server-Assisted External Configuration Mode #91

chasemaier opened this issue Aug 29, 2020 · 1 comment

Comments

@chasemaier
Copy link

Note: Comments here are based off looking at the "v2 alpha" branch.


It looks like the current setup of the tool is to be 100% static which makes sense. Since there is a huge variety of client tools that take an IAM key + secret and allow you to manage S3, I have a bit different idea of how this might be useful (at least to me).

I have a variety of cases when I need to give a non-technical user a UI to manage a specific S3 bucket where a bunch of the configuration options become a bit overkill:

image

E.g. I'd prefer to not create a dedicate IAM user and give out those credentials (which could then be used in any tool) if I already have a server setup with server-side access to S3 (e.g. via an IAM Role).

My thought is there could be a mode where:

  • A webhook URL is defined somewhere in the static site assets when the aws-js-s3-explorer deployed (alternately, simply in the query string when visiting the site so different webhook endpoints could be used by just giving different end-users different links). This could act also as a flag to indicate you want to use server-provisioned credentials.
  • The user visiting the static page is prompted for a password (or username + password, or just rely on the fact they have an established session in their browser with the webhook server already... either way -- probably makes sense to be a configuration option).
  • The static page makes an AJAX request with this authentication information to the provided webhook URL and gets back some set of credentials that would identify the bucket name, credentials, etc... (e.g. the webhook host could be a ec2 instance, fargate task, or lambda function with a role that already has bucket access and could delegate that to the web visitor).

Just an idea of what would be useful for me. If I were to use something like this, I'd almost always want it to be where the end-user shows up, puts in a simple password (stuff they're used to doing) and is immediately able to skip all manual configuration (and is also already in the bucket that is relevant for them).


Side Note: Since this is a simple 100% static tool. It'd be nice if AWS/this repo just hosted the latest version in a bucet/on GH pages at a predictable URL and could be used directly (any configuration being done via query string parameters). It'd make it easy to have a "see it in action" link in the README and would also give folks the option to just use it directly and not deploy their own bucket just to host the tool.

@wparad
Copy link

wparad commented Aug 31, 2021

Would utilizing Cognito to log in get around this problem as in #84, #85?

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