search

KYOSS / kyoss-topic-manager

A web application to allow members of KYOSS to vote on topics for meetings.
Apache License 2.0
3 stars 5 forks source link

Authentication Option? #5

Open InfoSec812 opened 10 years ago

InfoSec812 commented 10 years ago

Should, and if so how, the application require authentication to vote? Some possibilities include:

Google OAuth? Tie into the kyoss mailing list database? Other social media auth token (LinkedIn, Meetup, Facebook, etc...)?

ghost commented 10 years ago

I like mailing list for synchronization reasons, but from a development standpoint, an api story involving SM would be good. I'd like to fallback in that order and offer both, if not all, options.

InfoSec812 commented 10 years ago

SM???

ghost commented 10 years ago

Social media

clrockwell commented 10 years ago

OAuth 2 is widely adopted by the majors (LinkedIn, Github, Facebook, etc.) and would provide the most flexibility (e.g. an implementation could use just Github, another just Facebook, another all of them). I don't see any reason why that wouldn't be our plan.

I don't particularly care for requiring a user to be registered on the KYOSS mailing list because:

  1. User might not be on the list (just this past meeting had a couple signing John's sheet)
  2. User might not want to be on the list
  3. We'd have to build out an authentication plugin for it and the kyoss mailing list is, for lack of a better term, proprietary -- if this is truly open sourced we'd be tying future implementations to using specific software that isn't yet open source

If the group wants to add mailing list membership as a requirement for our specific implementation of the app, I would suggest we use OAuth and then, as an add-on of sorts, confirm that verified email address against the KYOSS mailing list database.

Finally, and this should probably be a separate issue, but what I see as more important than authenticating against KYOSS database, is that the app scoring system takes into account the attendance of members. This most likely would not be an issue with us, but I can imagine a situation in which 50 people are casting equal amounts of votes, but only 10 are actually showing up with any frequency. I could see this causing issues, and abandonment, should other groups decide to adopt whatever solution we come up with.

InfoSec812 commented 10 years ago

Those are all good points. I tend to prefer OAuth2 myself, but that's not to say that in a future iteration that we couldn't create an OAuth2 implementation on top of the mailing list's user database.

Deven

On Fri, Jul 11, 2014 at 12:38 PM, Chris Rockwell notifications@github.com wrote:

OAuth 2 is widely adopted by the majors (LinkedIn, Github, Facebook, etc.) and would provide the most flexibility (e.g. an implementation could use just Github, another just Facebook, another all of them). I don't see any reason why that wouldn't be our plan.

I don't particularly care for requiring a user to be registered on the KYOSS mailing list because:

  1. User might not be on the list (just this past meeting had a couple signing John's sheet)
  2. User might not want to be on the list
  3. We'd have to build out an authentication plugin for it and the kyoss mailing list is, for lack of a better term, proprietary -- if this is truly open sourced we'd be tying future implementations to using specific software that isn't yet open source

If the group wants to add mailing list membership as a requirement for our specific implementation of the app, I would suggest we use OAuth and then, as an add-on of sorts, confirm that verified email address against the KYOSS mailing list database.

Finally, and this should probably be a separate issue, but what I see as more important than authenticating against KYOSS database, is that the app scoring system takes into account the attendance of members. This most likely would not be an issue with us, but I can imagine a situation in which 50 people are casting equal amounts of votes, but only 10 are actually showing up with any frequency. I could see this causing issues, and abandonment, should other groups decide to adopt whatever solution we come up with.

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-48753358 .

jzan commented 10 years ago

I second Chris' concerns that voting should be allowed or weighted by an authenticated members attendance history. Perhaps the application should track separately the points total, frequent attendees total and a separate number for unregistered or not logged in? On Jul 11, 2014 12:38 PM, "Chris Rockwell" notifications@github.com wrote:

OAuth 2 is widely adopted by the majors (LinkedIn, Github, Facebook, etc.) and would provide the most flexibility (e.g. an implementation could use just Github, another just Facebook, another all of them). I don't see any reason why that wouldn't be our plan.

I don't particularly care for requiring a user to be registered on the KYOSS mailing list because:

  1. User might not be on the list (just this past meeting had a couple signing John's sheet)
  2. User might not want to be on the list
  3. We'd have to build out an authentication plugin for it and the kyoss mailing list is, for lack of a better term, proprietary -- if this is truly open sourced we'd be tying future implementations to using specific software that isn't yet open source

If the group wants to add mailing list membership as a requirement for our specific implementation of the app, I would suggest we use OAuth and then, as an add-on of sorts, confirm that verified email address against the KYOSS mailing list database.

Finally, and this should probably be a separate issue, but what I see as more important than authenticating against KYOSS database, is that the app scoring system takes into account the attendance of members. This most likely would not be an issue with us, but I can imagine a situation in which 50 people are casting equal amounts of votes, but only 10 are actually showing up with any frequency. I could see this causing issues, and abandonment, should other groups decide to adopt whatever solution we come up with.

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-48753358 .

InfoSec812 commented 10 years ago

I agree that non-attending members "could" become a problem, but I suggest that we not abandon democracy for a mere possibility at the outset.. If it becomes necessary to do something about "malicious" or "problem" voters at some point, then we should add a story to the backlog to handle that.

Here's my reasoning... If you are a new member or have for other reasons only been able to participate via the Internet up to a certain point; you would not have voting rights. Also, we often broadcast the meetings on-line, so the people who view those recordings should have some say in the content. Finally, by saying that only regular attendees can vote (or they get a disproportionate vote) it could create a culture of "I'm a more important member of KYOSS than you are", which I hope we all want to avoid.

clrockwell commented 10 years ago

I'm good with handling it that way.

Chris Rockwell

On Fri, Jul 11, 2014 at 1:57 PM, Deven Phillips notifications@github.com wrote:

I agree that non-attending members "could" become a problem, but I suggest that we not abandon democracy for a mere possibility at the outset.. If it becomes necessary to do something about "malicious" or "problem" voters at some point, then we should add a story to the backlog to handle that.

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-48762325 .

ghost commented 10 years ago

Let's go with that then!!

Chris, you are right, that probably should be another issue. I see it as taking attendance, which ties into my vision of a historical account of each meeting. This would give us a place to host the recordings, and more or less track the minutes. If there were powerpoint slides involved, etc, this would be a great place to host them.

I'd like to see each topic transform from pending in the selection queue, to an overview of what went down in a chronological report. From there, we can segue that right in to a what-went-well | what-could-be-improved style of comment section. From my experience, that type of review is enjoyable because it is effective for learning and at the same time being involved in that steady progression. Agile-scrum methodologies do something very similar during the sprint-review.

InfoSec812 commented 10 years ago

Ultimately, the decision of which option we will use lies with the product owner (John)... I'm sure he will take all of these discussions into account when making a decision...

Deven

On Fri, Aug 8, 2014 at 9:47 AM, Ryan Stortz notifications@github.com wrote:

Let's go with that then!!

Chris, you are right, that probably should be another issue. I see it as taking attendance, which ties into my vision of a historical account of each meeting. This would give us a place to host the recordings, and more or less track the minutes. If there were powerpoint slides involved, etc, this would be a great place to host them.

I'd like to see each topic transform from pending in the selection queue, to an overview of what went down in a chronological report. From there, we can segue that right in to a what-went-well | what-could-be-improved style of comment section. From my experience, that type of review is enjoyable because it is effective at incremental progression. Agile-scrum methodologies do something very similar during the sprint-review.

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-51602483 .

idkaaa commented 10 years ago

What about giving non-members a lower point value? Like 1 or 2 points?

InfoSec812 commented 10 years ago

We have to authenticate those users somehow or all they would have to do is clear their cookies to vote again and again...

On Thu, Aug 14, 2014 at 12:23 PM, idkaaa notifications@github.com wrote:

What about giving non-members a lower point value? Like 1 or 2 points?

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-52206296 .

idkaaa commented 10 years ago

right. "PendingMember" status?

InfoSec812 commented 10 years ago

What would that mean in our context? Either you are a member (you signed up on the site) or you are not... It's not like there is an approval process... Or am I not understanding your question?

On Thu, Aug 14, 2014 at 12:25 PM, idkaaa notifications@github.com wrote:

right. "PendingMember" status?

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-52206623 .

idkaaa commented 10 years ago

I think you got it. Say they can register, but until they are approved, they are given a temporary status with limited privileges.

InfoSec812 commented 10 years ago

But there is no "approval" required... Signing up for the site is instantaneous...

On Thu, Aug 14, 2014 at 12:28 PM, idkaaa notifications@github.com wrote:

I think you got it. Say they can register, but until they are approved, they are given a temporary status with limited privileges.

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-52206956 .

idkaaa commented 10 years ago

So this is only for people who have been added to the mailing list/KYOSS database? We wouldn't allow interested lurkers to vote? ie. there is no KYOSS signup page, correct?

InfoSec812 commented 10 years ago

Signing up on the Web site is separate from the mailing list.

Deven Phillips from my mobile On Aug 14, 2014 12:36 PM, "idkaaa" notifications@github.com wrote:

So this is only for people who have been added to the mailing list/KYOSS database? We wouldn't allow interested lurkers to vote? ie. there is no KYOSS signup page, correct?

— Reply to this email directly or view it on GitHub https://github.com/KYOSS/kyoss-topic-manager/issues/5#issuecomment-52207981 .

idkaaa commented 10 years ago

Perhaps that is a feature best left for a later story. (If the signup page works like I think it does)

I imagine existing authentication implementation systems could authorize certain users at signup time. Perhaps a secret word entered in a box to let the system know, "Oh, this guy/gal is a legit member, I'll assign them an authorized status in the database instead of a temp status". Then add a bit of if/then logic to assign point values to those with "temp status".

I definitely agree that feature is likely outside the scope of our current project. (I'm a dreamer, not a doer)