I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Could you explain what's happening in any of these screenshots? I've only limited exposure to MongoDB so I don't know if you're doing something it supports out-the-box or something else.
How is the password stored? Is it hashed or encrypted in some way? The usual way of checking a user's password is to apply the same hashing algorithm to the entered string and compare the result rather than to compare the literal password, because that requires you to store it in some what that's reversible.
If you're talking about APIs, then access tokens would be more practical, wouldn't they?
As an aside, if you include your code as Markdown code snippets (with the three backticks) then they'll be accessible to users who use screen readers or who want to zoom or change the contrast of their text.
Mechanic by trade, software dev because it's fun as heck. And, well, it will be nice to WFH when I decide my body has had enough. No commute, A/C, less silica glistening in the early morning air!
How is the password stored? Is it hashed or encrypted in some way? The usual way of checking a user's password is to apply the same hashing algorithm to the entered string and compare the result rather than to compare the literal password, because that requires you to store it in some what that's reversible.
While true, you would still need to access the hashed password to compare against, right? So, while you may need that field for authentication, you wouldn't want that field to be returned when returning a list of Users (i.e. searching for other Users to follow/add/etc.)
I'm making an assumption, but I think thats what the author meant.
If you're talking about APIs, then access tokens would be more practical, wouldn't they?
I'm still learning, so correct me if I'm wrong. Outside of using your Google or other account to sign in to an app with the token you get from that service, a user would need to use a password to create an account and authenticate with when signing in. Either way, there would need to be a list of hashed passwords to authenticate against.
Mind you, I'd probably keep them in a table separate from Users with just 3 columns: id (PK), user_id (FK), and password_hash. Then there's no need to strip anything from a query for Users because the passwords are stored separately.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Could you explain what's happening in any of these screenshots? I've only limited exposure to MongoDB so I don't know if you're doing something it supports out-the-box or something else.
How is the password stored? Is it hashed or encrypted in some way? The usual way of checking a user's password is to apply the same hashing algorithm to the entered string and compare the result rather than to compare the literal password, because that requires you to store it in some what that's reversible.
If you're talking about APIs, then access tokens would be more practical, wouldn't they?
As an aside, if you include your code as Markdown code snippets (with the three backticks) then they'll be accessible to users who use screen readers or who want to zoom or change the contrast of their text.
While true, you would still need to access the hashed password to compare against, right? So, while you may need that field for authentication, you wouldn't want that field to be returned when returning a list of Users (i.e. searching for other Users to follow/add/etc.)
I'm making an assumption, but I think thats what the author meant.
I'm still learning, so correct me if I'm wrong. Outside of using your Google or other account to sign in to an app with the token you get from that service, a user would need to use a password to create an account and authenticate with when signing in. Either way, there would need to be a list of hashed passwords to authenticate against.
Mind you, I'd probably keep them in a table separate from Users with just 3 columns: id (PK), user_id (FK), and password_hash. Then there's no need to strip anything from a query for Users because the passwords are stored separately.