search

arow-oss / goat-guardian

Reverse proxy that handles authentication
MIT License
39 stars 1 forks source link

road map (what features should go into the MVP) #3

Open cdepillabout opened 6 years ago

cdepillabout commented 6 years ago

This issue is to track/debate which features will go into the MVP.

We can also decide what to do immediately after releasing the MVP.

@arowM wrote the following https://github.com/arow-oss/goat-guardian/issues/2#issuecomment-402017450:

I have a question. What do you planing to do just after MVP release? Just publishing to hackage (and stackage), or also posting to reddit (and/or any service)? The requirements for MVP is various depending on the perspective.

My response is as follows:

I was definitely planning on publishing goat-guardian to hackage when we have a reasonable feature-set. I think it would also be a good idea to add a post to the ARoW blog. I think it might be a good idea to post to reddit because people there might find it interesting. However, it might make sense to hold off until we have more features.

arowM commented 6 years ago

Thanks for creating the issue.

I think the word "MVP" is similar to "Proof of concept", so it should gather some feed backs by other people. From this point of view, it is recommended to consider what feed backs should we get. If it is about vulnerabilities, we might have to implement email auth, e.g., password reset, changing password,..., which I guess easily causes vulnerabilities.

cdepillabout commented 6 years ago

@arowM I was thinking that "MVP" meant goat-guardian would provide a minimum amount of features that would be actually useful. So it would provide just enough features for us to be able to use it on our next project, but no more. Ideally it would also be useful for other people as well (not just us). I was thinking that goat-guardian would still be useful to us (and other people) even if it did not do email-based authentication.

However, if you're thinking it would be a better idea to just do a "proof of concept" in order to get some feedback about potential vulnerabilities, then maybe we should focus on that instead.

If we want to get feedback on potential vulnerabilities, then I think it is worth it to implement email-based authentication before doing other issues.

What do you think? Should we aim for more of a "proof of concept"? Or should we continue working towards more of an "MVP"?

arowM commented 6 years ago

I got it. There are two problems about "MVP".

  1. The next our project does not use twitter auth but uses facebook auth (so what we creating is not the "MVP" actually...)
  2. The importance of goat guardian is larger than our next project (so "MVP" is not as important as "Proof of concept")

So, I guess it is better to think about "Proof of concept" rather than "MVP".

Here is my thoughts about our road map (just an idea): i. release goat guardian and obtain feed backs ii. enhance Tonatona iii. fix goat guardian by feed backs iv. our next project v. fix goat guardian by feed backs from our next project

cdepillabout commented 6 years ago

Okay, this sounds good. I'll go ahead and add a "proof of concept" milestone.

I'll assign things to "proof of concept" vs "MVP" vs "after MVP" as I see fit when creating an issue, but please feel free to change the assignment if you think something should go somewhere else.

arowM commented 6 years ago

In your thought, which order to handle these milestones?

Is "MVP" after "proof of concept"?

cdepillabout commented 6 years ago

I'm sorry, I should have specified that.

I think that the "proof of concept" comes before the "MVP".

I've registered 3 milestones on GitHub. I think they should be done in this order:

  1. proof of concept
  2. MVP
  3. after MVP
cdepillabout commented 6 years ago

I have basically finished the email authentication code from #2. It is working well enough for a proof-of-concept (although the error cases and routing are not being handled very well).

With this done, we don't have any more big issues left before the proof-of-concept release.

The only two issues left are the following:

The logout handler should be very simple to do.

The README will take more time. We also must decide how much information we want in the README. I will update #13 with some comments about this.

@arowM, would you be able to take a look at the current code and let me know what you think? Should we go ahead with the proof-of-concept release? Or is there more that should be implemented?

(Although, it might be easiest to look at the current code after I put some instructions in the README for how to run Goat Guardian.)

cdepillabout commented 6 years ago

One thing I forgot to add:

Should we release goat-guardian to Hackage? Since goat-guardian uses Tonatona, I guess we should release Tonatona to Hackage before we release goat-guardian.

Is Tonatona in a state where we want to release it to Hackage? Should I focus on adding more documentation to the Tonatona plugins?

arowM commented 6 years ago

I'll create a library to resolve an problem that tonatona's default env variables have TT_ prefix.. How about release tonatona and goat-guardian after resolving above tonatona issue?

cdepillabout commented 6 years ago

I have implemented the logout handler, so now the only thing left is the README.

cdepillabout commented 6 years ago

Goat Guardian should be ready to be released as soon as #28 has been merged in. There are no other proof-of-concept issues left.