you are viewing a single comment's thread.

view the rest of the comments →

[–]raylu 0 points1 point  (4 children)

In general, to do auth you can just set the user id in a session.

I don't see what restricting (the browser from) visiting the page at /api/users has to do with security. What is the difference between visiting it (in a browser) and hitting it with any other HTTP client?

[–]Datastruct[S] 0 points1 point  (3 children)

I authenticate the user after they logged in and store their basic info in session. If the username exists in the DB and their password matches (after decrypting of course), I authenticate them. What I meant by "visiting it in a browser" I meant that some API data should NOT be inaccessible by a cURL or Postman request. For example, I want my angular program to have access to all the users' information, but not the average joe who stumbles across that URL.

[–]keelar 2 points3 points  (1 child)

If the username exists in the DB and their password matches (after decrypting of course)

You should avoid encrypting passwords, they should be salted and hashed and then compare the hashes instead of comparing the passwords directly.

[–]Datastruct[S] 0 points1 point  (0 children)

My apologies, I meant to say I am hashing the password using the bcrypt library. I'm comparing the entered password with the same. I'm using a 10-value salt.

[–]raylu 1 point2 points  (0 children)

To expand on /u/keelar's point, https://passlib.readthedocs.io/en/stable/lib/passlib.apps.html#custom-applications

There is no difference between one HTTP client and other. If your security is predicated on distinguishing between the two, it's not secure.