You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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.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.
The text was updated successfully, but these errors were encountered: