/
Authentication API endpoints and utilities

Authentication API endpoints and utilities

 

Logging in

  • /login

    • Body: email=?&password=?

    • Description: The login route, accepts two pairs of x-www-form-urlencoded input from the user, the email and password. The backend then validates the credentials with the database and then returns a Set-Cookie header in the response if it is successful.

    • Sample Request Packet:

      • POST /login HTTP/1.1 Host: cms.csesoc.org Content-type: applicaiton/x-www-form-urlencoded Content-Length: 43 email=someemail@gmail.com&password=password

         

    • Sample Response Packet:

      • HTTP/1.1 301 Moved Permanently Location: cms.csesoc.org/dashboard Set-Cookie: session-token=MTYzMjA0MzQ4NXxEdi1CQkFFQ180 SUFBUkFCRUFBQVlQLUNBQUVHYzNSeWFXNW5EQVlBQkhWelpYSWVSR2 xtWmxONWJtTXZhVzUwWlhKdVlXd3ZjMlZ6YzJsdmJpNVZjMlZ5XzRN REFRRUVWWE5sY2dIX2hBQUJBZ0VGUlcxaGFXd0JEQUFCRFVGMWRHaG xiblJwWTJGMFpXUUJBZ0FBQUJyX2hCY0JFbXBoYm1VdVpHOWxRR2R0 WVdsc0xtTnZiUUVCQUE9PXx6qDg5YuU9Ssbfdlsf_lYHKQ6SqBoT9z FCdsGFuAvOmw==; Path=/; Expires=Sun, 19 Sep 2021 09:39:45 GMT; Max-Age=900; HttpOnly
    • Explaination: The Set-Cookie header basically tells the browser to store this cookie in its local cookie storage, in the form HttpOnly, thus this cookie cannot be accessible with javascript like such document.cookie.

Authorization

  • Sending the cookie with every privileged request

    • Once the user is logged in, all subsequent protected route must send the cookie as a header to the request.

  • Sample Request

    • GET /dashboard HTTP/1.1 host: cms.csesoc.org Cookie: session-token={LONG_COOKIE};
  • Sample Response

    • HTTP/1.1 200 Success Access-Control-Allow-Origin: cms.csesoc.org Access-Control-Allow-Credentials: true
  • Explaination: Sending any request with the cookie embedded in the header must have credentials: true set in the request. For example using Fetch API it would look something like this fetch(BACKEND_URI, {credentials: true}).then(). Furthermore, In the back end the server must respond with Two crucial headers Access-Control-Allow-Origin: cms.csesoc.org where the backend whitelists the frontend URI as well as Access-Control-Allow-Credentials: true. Only then, will the cookie be sent to the backend.

  • Furthermore Access-Control-Allow-Origin:* is NOT allowed, when credentials i.e. cookies are to be sent.

  • After the cookie is sent to the backend, the utility functions will verify that a valid session is in place and then will send corresponding user data accordingly.

Logout

  • /logout

    • Header: Cookie: session-token={token}

    • Description: if the cookie is associated to a valid session, the backend will nullify the session and also respond with a header which will automatically remove the cookie from the user’s local cookie store. If the cookie sent is not valid, the backend will still respond with a header which Removes the invalid cookie in the user’s storage as well as redirect the user to the login page.

    • Sample Request Packet

      • POST /logout HTTP/1.1 Host: cms.csesoc.org Cookie: session-token={LONG_COOKIE}
    • Sample Response Packet

      • HTTP/1.1 Moved Permanantly 301 Location: cms.csesoc.org/login Set-Cookie: session-token=""; Path="/"; Max-Age=-1; HttpOnly

 

Related content

UNSW CSESoc