authentication

[slmyers]

from use cases:

Username is already in use

• why can't users be logged in from two different devices?

Special Character Filtration (Such as various ASCII symbols)

• is this truly necessary?

Explicative Filtration

• seems unnecessary. Better uses of time?

general

• perhaps we should move to email/password pair instead of username/password ?
• currently the username/password is sent as URL parameters, perhaps this should be changed to being sent in an JSON data attachment?

[theresa-cy-ngo]

I'm not entirely sure about these points since I didn't write the use cases, but let's see...

1. Is this from the exception from the first use case? I don't think it means that they can't be logged in from two different devices. Err... rather, I think the first two use cases got switched...? Since the basic flow for "Log into website" sounds more like "Register for website" and vice versa. So I think it means that the system checks whether or not another user already has an account using that username?
2. Not sure. If the usage of special symbols doesn't affect saving and retrieving information from the database (like ! turning into &#33 or something and for some reason, causing problems with logging in), then probably not? I know it causes issues for some things, but not everything.
3. Understandably there, but I agree with you. Potential very minor stretch goal?
4. Since he said he wanted "name and email address" in the google form, changing to an email/password pair sounds good to me.
5. ... I'm not too sure, but I feel like a JSON attachment would be safer? What do you think about it?

[slmyers]

I think it's probably better to send it in a JSON attachment, but I'm not too concerned about security in general.

Basically my plan for the authentication :

1. ignore filtering use case requirements
2. implement email/password combination

If I don't here any explicit disagreements I'll probably try to wrap these two up soon, and change the use cases in the docs.

Basically if people want:

1. expletive/special character filtering
2. JSON data attachment

They're going to have to implement it themselves.

[theresa-cy-ngo]

If everyone else is fine with it, I have no issues with it~ Anything I can help with over the next few days?

[slmyers]

Maybe change the use cases (in the docx file) to reflect the system we have + email/password combo?

[theresa-cy-ngo]

Done. I think.