search

uprzejmie-donosze / uprzejmiedonosze-backend

https://uprzejmiedonosze.net/
1 stars 0 forks source link

One user related endpoint working #3

Open szn opened 6 years ago

szn commented 6 years ago

One user related endpoint working.

Example CURL/HTTP request provided to prove it works.

mikaeilorfanian commented 6 years ago

@szn, @copalco user authentication using a social button won't be easy using the technologies we've decided to use so far. I suggest, we either add more technologies(for example using flask or Django for user authentication) or do a simple login using email. For example, we can ask user for their email address only after they take a picture and fill out the form. Then we ask the user for their email. They submit their report. we ask them to click on a link in their email to confirm sending the report. What do you guys think? @szn @copalco

szn commented 6 years ago

I would vote for the first option (expanding technology stack to keep social logins).

@copalco do you have anything against? Or suggestions about the technologies to use?

mikaeilorfanian commented 6 years ago

The issue here is that I can't find a library that simplifies social auth for falcon. But, there are such ready solutions for flask or Django. We don't have to throw away falcon. For example, we can use flask only for user authentication.

mikaeilorfanian commented 6 years ago

@szn actually, I just realized that social login should not be part of the back-end. It should be done on the front-end because the user needs to be redirected to a facebook login page and then back to our website. This logic should be coded on the front-end side. Once this flow is done(i.e. user goes to facebook login page and comes back to our page) the front-end should send us an email address. Then we save this email as new user and return a token for the user so that the user will not have to do a facebook login again. The front-end will have to save this token and use it in every call to our API(this is called token authentication). @szn @copalco what do you guys think?

szn commented 6 years ago

Almost correct. Most of the logic is done on client side. But server has to confirm that the data provided are valid. Take a look here: https://developers.google.com/api-client-library/python/auth/web-app

This usually means that there is a need for backend side code that receives access_token and convert it into a username/useremail.

Another example is here:

https://github.com/reddit/reddit/wiki/OAuth2-Python-Example

szn commented 6 years ago

I'll try to provide a sample HTML to test your future solution.

mikaeilorfanian commented 6 years ago

@szn This is the flow I have come up with (FE means front-end, BE means back-end): 1) User presses sign in with facebook button. FE makes the button and provides the link. 2) User is redirected to the facebook sign in page. 3) After successful sign in user comes back to our page. 4) FE sends user's email address to back-end. 5) BE saves user and makes a token for user. BE sends that token to FE. 6) FE saves this token and uses it in every API call to our BE. With this token, the user doesn't have to sign in using facebook anymore unless they use a different device or clears his/her cookies.

Only steps 4 and 5 have logic in the backed. Is this what you have in mind? I've already added token authentication to our API so that all endpoints require a valid token. Now, I'm doing an endpoint that takes user's email address and returns a token.

szn commented 6 years ago

I'm fine with what you wrote except one thing. I bet that backend should check if the email provided by frontend is valid.

Please check if there is a way to receive a token from FE and then obtain an email from FB/G+. More or less like that:

  1. User presses sign in with facebook/G+ button. FE makes the button and provides the link.
  2. User is redirected to the facebook/G+ sign in page.
  3. After successful sign in user comes back to our page.
  4. FE sends access_token to BE.
  5. BE saves user access_token and retrieves user's email from FB Graph API and/G+ services.
  6. BE creates a sessio_id/token for a user. BE sends that sessio_id/token to FE.
  7. FE saves this sessio_id/token and uses it in every API call to our BE.
  8. With this sessio_id/token, the user doesn't have to sign in using facebook/G+ anymore unless they use a different device or clears his/her cookies.
mikaeilorfanian commented 6 years ago

This is it. Now, I get what you mean by "token" from FB/G+. This is what we have so far: 1) User objects persistence in mongdb and different user management commands(find user by email address, find user by auth token, etc.): https://github.com/szn/uprzejmiedonosze-backend/commit/d1b7aa9487f823e082929108267eb75d50894e92 2) Token authentication so that all API calls to our server have to have a valid token; otherwise, the calls get rejected: https://github.com/szn/uprzejmiedonosze-backend/commit/652d84da0d106cc9708e4c1c930788ca5a958611

I'm going to start working on points 5 and 6 from your last comment. Hopefully, we'll have them ready by the time we meet on 16th.