Create User

[samcdavid]

The vast majority of projects we take at Spartan need a user account of some kind. Therefore an API endpoint needs to exist for creating a user.

Tasks:

• [ ] Create User storage
• [ ] POST /api/v1/user will create a user

User Attributes

• [ ] email (required)
• [ ] password (required)
• [ ] timestamps

[bryanenders]

I would say that starting with a user is an anti-pattern from the Rails world. For one, it becomes a dumping ground for data and functionality that belongs elsewhere. Secondly, authentication, authorization, and user logging may belong either in the core application or the delivery mechanism or a mix, depending on the business needs. We deferred authentication, authorization, and user logging to the end of the Guardian Trust engagement. In doing so we learned a lot about what we actually needed, and it was very different from what we expected going in.

Beyond that, I wouldn’t presume single-step, knowledge-factor (arguably one of the weakest and least user-friendly, though ubiquitous forms of) authentication. If we are using single-step, knowledge-factor authentication, I’d assume we are hashing passwords and storing and retrieving them in a manner that isn’t subject to the variety of time-based vulnerabilities.

It would be worth documenting a variety of approaches to all three distinct problems: authentication, authorization, and user logging.

[samcdavid]

If you use the kit and you don't need it, then it can just be yanked out. The vast majority of our projects require some kind of user auth and clients want something that is familiar. I'm also just going with the direction I was told to take the kit.

[bryanenders]

I really don’t think the kit should be a pre-built project. Mix makes it easy enough to build the project you want. This booster kit should probably be more like a reference for how to add different pieces and take advantage of everything OTP offers. Despite some superficial syntactic similarities, Elixir and Ruby are very different animals.

[mjs2600]

You can adapt the generation templates if we really want to spit out something preconfigured.

[bbrock25]

We need to have a pre-configured phoenix app for interfacing with our various clients. Thats what the kit is for. Maybe we have a separate repo for our adopted best practices?

[bryanenders]

Well, since the Phoenix app is not the core application... maybe we create a pre-configured umbrella app with a Phoenix app (the web delivery mechanism). The devs would then create the core app (where the business logic lives). A well architected core app wouldn't have any boilerplate anyway. All the boilerplate (non-domain code) would be in the delivery mechanism and umbrella. Does that make sense?

[bbrock25]

I think?

what we really need are a few core user flows to get us running, and if that can fit in that paradigm, great!

• create account
• login
• logout
• reset password
• update account settings

I know that a lot of this becomes domain specific once a project gets to a certain point but what we really need is consistent standards across projects for these various features so that the consumers/clients (react | ios | etc) can move faster without substantial refactors for each various backend.

[mjs2600]

Could we just make an account management library that wraps Ueberauth with the defaults baked in? Plug is really compossible, so overriding those defaults when we need to shouldn't cause any pain.

[bbrock25]

That sounds amazing. Ideally we can spin up a new client app and only change a few endpoints to interface with this app. I haven't worked with uberauth, but if its solid then lets give it a try.