Feature/be 19

[BElifb]

• Created 2 API's for password reset (without login/ forgot password case).
  • http://127.0.0.1:8000/api/v1/auth/request-reset/
    • Takes {
      "email": "user_email@artopia.com"
      }, and sends an email with a one time password to user.
  • http://127.0.0.1:8000/api/v1/auth/password-reset/
    • Takes {
      "email": "user_email@artopia.com",
      "otp": "six_digit_otp_from_email",
      "new_password": "new_user_password"
      }, and changes user password to new_password.
  • Prepared detail documentation with examples,on Swagger
    • http://localhost:8000/api/v1/swagger/schema/
• In order to test using local server, on a seperate terminal in the directory where manage.py is located (bounswe2022group8\App\backend) run py -m smtpd -n -c DebuggingServer localhost:1025 . Make sure that your virtual environment is active.
  • This is for testing and does not actually send emails. It confirms that email sending functionality is working. You can think of it as a box that catches emails instead of sending them. You should be able to see the email in the terminal. Although mine showed up instantly, I have read online that it could take a few minutes, so be patient.
• Finally if you want to test it with an actual email server you will have to set up a few things.
  • In the bounswe2022group8\App\backend\backend\settings\development.py file comment out Email Settings for testing locally and uncomment Email Settings .
  • Then define those variables in your local .env file. Which should be in the parent directory, since we also use it for docker.
  • If you're using Gmail, with the latest changes you must be using 2 factor authentication and set up Gmail app password. Follow these steps.
  • I searched for different email providers with free SMTP, but couldn't find any. Let me know if you do.
• Created another API for password update (through profile page/logged in).
  • http://127.0.0.1:8000/api/v1/profile/me/password-reset/
    • Takes {
      "new_password": "new_user_password"
      }, and updates user password.
  • User must be logged in (Token is checked).

[KarahanS]

I think we have to be consistent in the naming of our APIs. There are lots of resources but I believe this one provides some concrete TODOs and not TODOs.

Always make sure that your URIs are named with nouns to specify the resource instead of using verbs. The URIs shouldn’t indicate any CRUD (Create, Read, Update, Delete) operations. Additionally avoid verb-noun combinations: hyphenated, snake_case, camelCase.
We can rename our APIs as:

• http://127.0.0.1:8000/api/v1/auth/request/
• http://127.0.0.1:8000/api/v1/auth/password/

If you want to include reset as well (since it is also a noun):

Do not use underscores. Separating words with hyphens will be easy for you and others to interpret. It is more user-friendly when it comes to long-path segmented URIs.
So it would be something like:

• http://127.0.0.1:8000/api/v1/auth/request-reset/
• http://127.0.0.1:8000/api/v1/auth/password-reset/

[BElifb]

I don't see what's wrong with camelCase notation but if we're going to use hyphen convention, I can update it. Or maybe you can, showing exactly what the convention is. @KarahanS

[KarahanS]

• Hyphen convention is the way to go. It's the best practice according to ref.
• Also Google recommends hyphens.
• A more technical answer why we should use hyphens: ref-2.
• Another reason to embrace hyphens: ref-3. In summary:

It is recommended to use the spinal-case (which is highlighted by RFC3986), this case is used by Google, PayPal, and other big companies.

fyi @BElifb

[BElifb]

We have 3 APIs for password update (a couple for forgot case and another for logged in). Any ideas for naming without verbs?

[KarahanS]

reset seems ok since it's also a noun. I recommended these ones already:

• http://127.0.0.1:8000/api/v1/auth/request-reset/
• http://127.0.0.1:8000/api/v1/auth/password-reset/
  Is the other one related to profile page? Then:
• http://127.0.0.1:8000/api/v1/profile/me/password-reset/ as in feature/BE-16 #249.

[BElifb]

Thanks, I'll update them.

[KarahanS]

Are we going to create a generic email that sends mails to users for production? If so, could you set the environment variables accordingly for production.py as well? Here it mentions about how to use environment variables in .env file for docker-compose. I haven't tested it out yet but it would be nice to get the know-how here since we will be creating other environment variables as well for production. (When we learn how to use environment variables from docker containers, we can also put our database information to .env or something like this as well) @BElifb

[BElifb]

Are we going to create a generic email that sends mails to users for production? If so, could you set the environment variables accordingly for production.py as well? Here it mentions about how to use environment variables in .env file for docker-compose. I haven't tested it out yet but it would be nice to get the know-how here since we will be creating other environment variables as well for production. (When we learn how to use environment variables from docker containers, we can also put our database information to .env or something like this as well) @BElifb

• Yes, the way I've seen it is; we will either use a regular email account or create an app password through that account. I didn't want to use my personal email, and tried to find a free email provider that wouldn't demand 2 factor authentication (phone number) to create an account for the app. I tried several ones (like proton.me), but the ones without phone requirement didn't have free smtp servers. I'll look more into this and the env variables for production but right now I'm buried under the workload (from other classes etc.). So it might be a long while till I do, alternatively we can assign this to someone else. Either way I think it might be better to do this another PR, so that frontend team can get stared. @KarahanS

[KarahanS]

Ok, I think you can add a new checkbox to the related issue #254 which states that the configurations for production will be done and let the content of this PR to be only confined to development stage. I think you should be the one working on it btw since since you got familiar with the concept @BElifb
My first job is to review this PR after I have my exams on Monday and Tuesday.

[KarahanS]

As we talked in the meeting, there are several things to add to this PR:

• Password should be kept as sha256 encrypted in the database.
• An email account for the production environment should be configured and tested carefully.
  I'm marking this PR as in progress for now and waiting for your updates before reviewing it.

[KarahanS]

I updated the docker-compose file so that it takes .production.env file and reads it for the credentials. You can put the relevant information there.

[BElifb]

• Otp mechanism updated to include encryption.
• Changed development settings for Gmail. Tested with the app password provided by @ooodogodogodogo
  • Here's a screenshot of our first real e-mail.

• Secret information for testing, will be shared with the team seperately.

[serdarakol]

Everything looks fine and works as we have discussed. Thank you @BElifb for your effort.

[BElifb]

Solved merge conflicts with master. Last chance if anyone wants to check it out before merge, otherwise I'll conclude the PR.