User was banned for this post.
The Big Programming Thread - Page 1012
Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
kalitoma40
Italy1 Post
User was banned for this post. | ||
WarSame
Canada1950 Posts
Say I have a Debate, which has children Arguments.
What is your preferred method? Currently I'm trying 3, and using an endpoint like /api/d/<debate_id>/a/ to query it. Is there a potentially better URI format to use? | ||
tofucake
Hyrule18778 Posts
/api/debate/<debate_id>/argument/<argument_id>/<action> What I'd do in this particular situation would be something like GET /api/argument | ||
WarSame
Canada1950 Posts
By headers are you referring to query params? I could do that but I'm not sure why I should prefer that vs. a fully qualified URI. | ||
tofucake
Hyrule18778 Posts
| ||
WarSame
Canada1950 Posts
| ||
Silvanel
Poland4601 Posts
| ||
Manit0u
Poland17048 Posts
On November 11 2019 20:03 Silvanel wrote: What security concerns should i take into account before rolling out my webpage for limited use for my close friends on a private server? Standard XSS, SQL injection etc. For sure you want to encrypt passwords if you store them. | ||
Manit0u
Poland17048 Posts
| ||
ShoCkeyy
7815 Posts
On November 08 2019 13:07 WarSame wrote: Hmmmm, I see what you're getting at. Thanks! I'll consider that too. There's a lot to consider when building an API! You should also take a look into GraphQL, for readability it’s far far superior than REST. | ||
Excludos
Norway7686 Posts
On November 12 2019 23:38 Manit0u wrote: Standard XSS, SQL injection etc. For sure you want to encrypt passwords if you store them. The one and only solution for any programmer that doesn't work in a large corporation with their own needs: Never ever store user credentials. There's just too many fall pits. Just use OAuth instead. If you're at the point where you're unsure how you should store user details, and then go ahead and do it anyways, I can promise you will hack your website within the hour. What I can do from there just depends on how many mistakes you've done. | ||
Manit0u
Poland17048 Posts
On November 13 2019 03:50 Excludos wrote: The one and only solution for any programmer that doesn't work in a large corporation with their own needs: Never ever store user credentials. There's just too many fall pits. Just use OAuth instead. If you're at the point where you're unsure how you should store user details, and then go ahead and do it anyways, I can promise you will hack your website within the hour. What I can do from there just depends on how many mistakes you've done. For simple stuff storing user creds is perfectly fine. Especially that most major frameworks have pretty good libraries to handle that (where they encrypt your passwords - default is bcrypt, don't show them in logs etc.), even for API development you have libraries to handle JWT and other authentication methods. There are also plenty of libraries for authorization, but that's another matter. If he's new to that it'll be easier to use such things than setting up OAuth and integrating with third party authentication providers (where you add more traffic, need to set things up on the third party's side of things, have to think about stuff like how to revoke tokens, different authentication flows and the like, it's not beginner level endeavour). | ||
Excludos
Norway7686 Posts
On November 13 2019 06:01 Manit0u wrote: For simple stuff storing user creds is perfectly fine. Especially that most major frameworks have pretty good libraries to handle that (where they encrypt your passwords - default is bcrypt, don't show them in logs etc.), even for API development you have libraries to handle JWT and other authentication methods. There are also plenty of libraries for authorization, but that's another matter. If he's new to that it'll be easier to use such things than setting up OAuth and integrating with third party authentication providers (where you add more traffic, need to set things up on the third party's side of things, have to think about stuff like how to revoke tokens, different authentication flows and the like, it's not beginner level endeavour). Easier, yes, but vulnerable. If it's just for fun and you don't care about potentially being hacked, then by all means go ahead. We've all made sites like that. As long as you know it's vulnerable and have nothing to lose. | ||
R1CH
Netherlands10340 Posts
On November 12 2019 23:38 Manit0u wrote: Standard XSS, SQL injection etc. For sure you want to encrypt passwords if you store them. You should be hashing passwords using a modern algorithm like Argon2id, not encrypting them. Big difference. | ||
JimmyJRaynor
Canada15565 Posts
| ||
Manit0u
Poland17048 Posts
Really fun watch. Made me chuckle really hard. | ||
Manit0u
Poland17048 Posts
https://twitter.com/chrisalbon/status/1196136359636815872?s=20 | ||
Deleted User 3420
24492 Posts
I missed both of those parts. Apparently an automated script was checking the hash and ciphertext, and it didn't catch stuff like whitespace or newlines or something. So I checked, and my hash was correct. I informed the TAs of the error (which happened to lots of students). They then gave me the points back for the SHA portion. But I didn't get any points for the encryption part. So my question is, if I encrypted the message and then hashed the ciphertext, and the SHA hash was correct, then doesn't that mean that the ciphertext must have also been done correctly? | ||
Nesserev
Belgium2760 Posts
| ||
Deleted User 3420
24492 Posts
ok thanks thought so this post was more a sanity check than anything | ||
| ||