Closed tempestb closed 8 years ago
1) Create one account and put a user in each bucket. 2) Use this https://github.com/Storj/account-mapper, which does exactly that.
From what I see, Account-Mapper just creates the account with a bogus email address and password and returns those as values. I could setup my mail server to do the same thing, it's an ugly work around to something that could be handled gracefully by having Storj not send the confirmation email and instead allow activation during registration. I don't really see the point in the Storj API making email verification mandatory. Let the developer handle that.
It's ugly because you should not be creating accounts on behalf of users.
On Sep 23, 2016 11:17 AM, "tempestb" notifications@github.com wrote:
From what I see, Account-Mapper just creates the account with a bogus email address and password and returns those as values. I could setup my mail server to do the same thing, it's an ugly work around to something that could be handled gracefully by having Storj not send the confirmation email and instead allow activation during registration. I don't really see the point in the Storj API making email verification mandatory. Let the developer handle that.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Storj/bridge/issues/230#issuecomment-249220656, or mute the thread https://github.com/notifications/unsubscribe-auth/AADuLzDApUuO2Ro61hq9KPI3Y2BJr7tBks5qs-18gaJpZM4KEUlK .
Why not? If the purpose of the API is to build applications around Storj, why would we want the users to go outside our applications to build a Storj account? On one hand, you argued with me that Storj is not about you building a GUI and it would be beyond the scope of your project if you handled the interface for uploading files. On the other hand, you're saying that if I write that application, users need to go outside of it to register on the Storj network. What is the trouble in allowing activation at registration time? Email can be bogus. Any of us can go create a bogus email address in seconds. So I'm not clear on why Storj requires email verification. What's the issue?
It's fine. I'll just use one account and store everything in multiple buckets.
@tempestb this is in place simply to prevent abuse. In addition, in production, creating an account for a user will cause them to be billed separately from your app as well. This is why we encourage developers to create a bucket per user of their application (or a bucket per application and manage ownership from within your application).
Thanks, that makes sense. My only concern about this, is in the event Storj decides to ban a user for some reason. I am not sure Storj can ban users. Can it? I don't want Omar to post up ISIS's plans to build a nuclear weapon, and have all my user's buckets get banned because of one bad bucket. If I'm going to be the gate keeper of all the buckets, I would hope I would get notification to correct the issue if such a ban might take place.
Most likely the men in the black suits would contact you to remove it, not us. If we were contacted, we would probably just remove the files that were pointed out. We have no mechanism to know what files are stored unless someone gives us the publicly posted decryption keys.
Fair enough. Thanks for your time.
@tempestb No problem. Happy to help!
Currently when a user is created, Storj sends that user a confirmation email / token.
I want to use my own internal authentication mechanism and would like to bypass the Storj confirmation email and token generation process to simply activate the user by passing a command at creation time, such as "activated = true".
For instance, when a user creates an account on my website, the user account is generated both in my website's database table, and in Storj. (It performs all checks for valid, and has email authentication already.) This means that the user would get 2 emails. One for authenticating against the website, and one for authenticating against Storj, which is cumbersome. I think it would be ideal that at creation time, the Storj authentication via email could be bypassed.
Happy to discuss.