Programming thread

I'm completely sick of REST APIs. They sound like a good idea but they always make you jump through extra hoops like API keys,
What really irritates me is APIs that are meant to only ever be consumed by somewhere between one and a few automated services, which have to authenticate themselves to some stupid authentication function on the same endpoint with a username and password to get a token to then pass to the one or two functions that are actually used. Just let the client authenticate with password authentication to the actual functions FFS.

Pulling that is a good way to get people consuming your service to authenticate anew every single time they need to call any of the actually important functions, to avoid having to store key expiry info or handle expired auth error codes. Very efficient, much secure!
 
  • Agree
Reactions: Marvin
What really irritates me is APIs that are meant to only ever be consumed by somewhere between one and a few automated services, which have to authenticate themselves to some stupid authentication function on the same endpoint with a username and password to get a token to then pass to the one or two functions that are actually used. Just let the client authenticate with password authentication to the actual functions FFS.

Pulling that is a good way to get people consuming your service to authenticate anew every single time they need to call any of the actually important functions, to avoid having to store key expiry info or handle expired auth error codes. Very efficient, much secure!
Now that I can agree with. HTTP has had authentication at the protocol level since 1.0, I think. The main reason why most web sites don't use it in favor of an in-page form that works above the protocol is to provide a better UI, but that goes out the window when you're just doing an API. If there is some sort of benefit to the token approach, I'd love for someone smarter than me to explain it to me.
 
  • Agree
Reactions: Marvin
Now that I can agree with. HTTP has had authentication at the protocol level since 1.0, I think. The main reason why most web sites don't use it in favor of an in-page form that works above the protocol is to provide a better UI, but that goes out the window when you're just doing an API. If there is some sort of benefit to the token approach, I'd love for someone smarter than me to explain it to me.
It makes sense with third party apps for using sites like Twitter and Facebook- where you connect through, say, a Twitter page, and that gives the app a token it can use to authenticate to Twitter without giving the app your password. Unfortunately, some idiots insist on adding this totally worthless form of abstraction for B2B type services, where it's totally unneccessary.
 
  • Agree
Reactions: Marvin
@Yotsubaaa I have thought about what it would be like to thank about CS algorithms all day as an academic. I am at the point in my life/career where if I really committed to it, academia is possible. I don't think I'm brilliant at algorithms or anything but I think it could be a fun job. Well, better than trying to learn the latest framework every few years, if the reputation is true. That's what I respect about Knuth:
his work lives on for years while whatever JS framework of the day is forgotten in a few years.
I like to imagine myself with a nice office with bookshelves and chairs. A place where I can sit and think in quiet about algorithms with a notebook. And I would have a whiteboard too where I could draw ideas with other people. And I wouldn't be against teaching either because it can be pretty rewarding to teach about my interests. But academic positions are not handed out easily and I don't think I am so brilliant to get there without a long uphill climb. It may be more likely that I'm constantly trying to get funding or whatever in a dingy office.

I like the guy's voice. Maybe this is my future too. I think I've seen that exact pink gaming chair on amazon.
 
Now that I can agree with. HTTP has had authentication at the protocol level since 1.0, I think. The main reason why most web sites don't use it in favor of an in-page form that works above the protocol is to provide a better UI, but that goes out the window when you're just doing an API. If there is some sort of benefit to the token approach, I'd love for someone smarter than me to explain it to me.

Disclaimer: I believe the below to be true with a fair amount of certainty, but everything that I typically work with day to day where security is a concern typically eschews HTTP in favor of more secure standards like HTTPS et al so take this with a grain of salt;

HTTP Basic Auth relies on a person's username and password to be transmitted with little more protection than base64 encoding, so any skiddie running Wireshark can easily capture a request and decode those credentials, thus compromising the account. Tokens provide a secondary form of authentication that's only applicable for certain use cases (such as API requests) and thus mitigates the potential damage that can be caused by a MITM or side channel attack, they're typically long strings so they're harder to brute force than most peoples' passwords, and they're only useful within the context of API requests.


In other words, if a malicious actor gains access to the contents of a request using token auth, they only gain access to API functions and still can't log in "as" you via the primary service interface (website/application), they don't suddenly have a user-generated password that may be reused elsewhere to try and compromise someone's email etc.

@Yotsubaaa I have thought about what it would be like to thank about CS algorithms all day as an academic. I am at the point in my life/career where if I really committed to it, academia is possible. [...]
But academic positions are not handed out easily and I don't think I am so brilliant to get there without a long uphill climb. It may be more likely that I'm constantly trying to get funding or whatever in a dingy office.

Side hustle that shit, man. I'd say your biggest goals are going to be knowledge, portfolio, and reputation in that order. Study any areas you might not have a thorough understanding of in regards to the foundational principals of algorithmic functions and their application in CS, contribute to/start open source projects that provide (at least theoretical) benefit to people, and maybe start a blog or social media account documenting your intellectual travels. Build academic equity outside of traditional career elements and create a paper trail would-be employers can see/that you can produce on request in addition to your resume, as proof of said equity.

If you don't give up before you've given this a fair shot, you should be rewarded with an accurate outlook on if your aspiration is really one that would be rewarding to dedicate your professional life to, or if it's based on naive notions of what that life would be like and would in reality be a soul sucking grind. Either you'll find your passion growing as you get the hang of things and a legitimate sense of accomplishment and excitement as you accomplish small goals, or you'll find yourself constantly exhausted and frustrated. The former will act as evidence that you're on the right path, and the latter will serve as a canary to let you know you should get the hell out of this mine before you get in too deep and can't turn back.

I like the guy's voice.
The guy has a legitimately enjoyable voice. He should do voice work of some sort.

Maybe this is my future too. I think I've seen that exact pink gaming chair on amazon.
So it begins...
 
Disclaimer: I believe the below to be true with a fair amount of certainty, but everything that I typically work with day to day where security is a concern typically eschews HTTP in favor of more secure standards like HTTPS et al so take this with a grain of salt;

HTTP Basic Auth relies on a person's username and password to be transmitted with little more protection than base64 encoding, so any skiddie running Wireshark can easily capture a request and decode those credentials, thus compromising the account. Tokens provide a secondary form of authentication that's only applicable for certain use cases (such as API requests) and thus mitigates the potential damage that can be caused by a MITM or side channel attack, they're typically long strings so they're harder to brute force than most peoples' passwords, and they're only useful within the context of API requests.

In other words, if a malicious actor gains access to the contents of a request using token auth, they only gain access to API functions and still can't log in "as" you via the primary service interface (website/application), they don't suddenly have a user-generated password that may be reused elsewhere to try and compromise someone's email etc.
Yeah, my comments are in the context of HTTPS only (and often services that go over VPNs or at least are only available to IP-whitelisted users).
 
  • Like
Reactions: Marvin
HTTP Basic Auth relies on a person's username and password to be transmitted with little more protection than base64 encoding, so any skiddie running Wireshark can easily capture a request and decode those credentials, thus compromising the account. Tokens provide a secondary form of authentication that's only applicable for certain use cases (such as API requests) and thus mitigates the potential damage that can be caused by a MITM or side channel attack, they're typically long strings so they're harder to brute force than most peoples' passwords, and they're only useful within the context of API requests.
But if you're using HTTPS, then the entire connection is encrypted at a lower level, so the auth credentials are encrypted too. HTTPS requests aren't unencrypted; the SSL handshake happens first, then the client and server spit encrypted data back and forth.
 
  • Like
Reactions: Marvin
Side hustle that shit, man. I'd say your biggest goals are going to be knowledge, portfolio, and reputation in that order. Study any areas you might not have a thorough understanding of in regards to the foundational principals of algorithmic functions and their application in CS, contribute to/start open source projects that provide (at least theoretical) benefit to people, and maybe start a blog or social media account documenting your intellectual travels. Build academic equity outside of traditional career elements and create a paper trail would-be employers can see/that you can produce on request in addition to your resume, as proof of said equity.

If you don't give up before you've given this a fair shot, you should be rewarded with an accurate outlook on if your aspiration is really one that would be rewarding to dedicate your professional life to, or if it's based on naive notions of what that life would be like and would in reality be a soul sucking grind. Either you'll find your passion growing as you get the hang of things and a legitimate sense of accomplishment and excitement as you accomplish small goals, or you'll find yourself constantly exhausted and frustrated. The former will act as evidence that you're on the right path, and the latter will serve as a canary to let you know you should get the hell out of this mine before you get in too deep and can't turn back.
I should say my primary area is not CS or Math but something that involves both (statistics). I've been applying to internships but I don't think recruiters have actually looked at my github. A lot of companies want me to do a stupid online coding challenge or whatever which I guess saves them time from the absolute idiots who can't write anything I guess. But none I've applied for are truly interesting. Maybe because they're internships.
 
  • Feels
Reactions: Yotsubaaa
@Yotsubaaa I have thought about what it would be like to thank about CS algorithms all day as an academic. I am at the point in my life/career where if I really committed to it, academia is possible. I don't think I'm brilliant at algorithms or anything but I think it could be a fun job. Well, better than trying to learn the latest framework every few years, if the reputation is true.
You mentioned later down that you've got a statistics background, so actually I think you're in an awesome place for academia (and industry too, to be honest). My current job has me at a weird boundary between private industry and academia, which gives me the best (and worst...) of both worlds, but also gives me a great vantage point to see trends in both. And I really believe statistics/proper experiment design/etc is going to become a major thing in the next couple of decades. I see that a lot of academics (and, more importantly, their stakeholders) are starting to get pissed off with the lack of proper analysis and reproducibility that happens in modern research. So you're probably in a pretty great position to leverage your statistical skill set if you did want to go down the academia road.

That's what I respect about Knuth:
his work lives on for years while whatever JS framework of the day is forgotten in a few years.
Knuth is awesome. He needs to finish his Art of Computer Programming manifesto before he dies, but since he seems to enjoy the 'George R. R. Martin' style of procrastination, I'm sure it's not gonna happen.

I like to imagine myself with a nice office with bookshelves and chairs. A place where I can sit and think in quiet about algorithms with a notebook. And I would have a whiteboard too where I could draw ideas with other people.
That's definitely a part of the job (although not as large a part of the job as you'd probably like it to be).

And I wouldn't be against teaching either because it can be pretty rewarding to teach about my interests.
Teaching is a funny thing in academia. There's negative incentive to be a good teacher, since it really cuts into your research time and time spent upskilling/preparing lectures is never appreciated by anyone. You don't often get to pick your classes either—that's administration's job, and they love picking favorites and punishing people they don't like. The typical attitude I've seen from academics is to put the bare minimum effort into your teaching load and to not piss off the head of your department ("Oh, @awoo said he doesn't like the way I'm running my department, huh? Well guess who's stuck teaching Baby's First Programming Class 101 for the next couple of semesters!")

I underlined the section about how teaching really cuts into your research time because that can't possibly be stressed enough. @cecograph mentioned the 'publish-or-perish' paradigm before, and it's the law as far as academia is concerned. There's a reason your department head will use teaching loads to punish subordinates that he doesn't like. Other people (including your peers, your department heads, your stakeholders, the grants committee, other universities/institutions) will 100% base their opinion of you off of your publishing record. Nobody gives a fuck how good of a teacher you are, and especially not if it's cutting into time that you could've otherwise used to publish stuff. And inversely: nobody gives a fuck how bad of a teacher you are either (as long as the volume of complaints isn't large enough that admin has to step in and do something about it), which is why the teaching situation in higher education is the shitshow that it is.

But academic positions are not handed out easily and I don't think I am so brilliant to get there without a long uphill climb. It may be more likely that I'm constantly trying to get funding or whatever in a dingy office.
It's going to be hard work and there are certainly going to be the downsides, of course (like any job). You have to really want to be doing research and to be in that academic setting that is (arguably?) most conducive to that research. Particularly when you're still starting out at post-doc level, there will always be that pressure to drop it all and 'settle' for an industry (or contract) job where you're earning over twice as much money with better job security, and actually looking at new, interesting things and helping solve problems that people actually give a fuck about.
 
  • Informative
  • Like
Reactions: awoo and cecograph
"Oh, @awoo said he doesn't like the way I'm running my department, huh? Well guess who's stuck teaching Baby's First Programming Class 101 for the next couple of semesters!"
On the other hand though, the teaching style and content of the course seems to be almost entirely dictated by whatever the hell the professor wants to do, so you can make it a weed-out course if you really want to.
 
  • Agree
Reactions: Yotsubaaa
On the other hand though, the teaching style and content of the course seems to be almost entirely dictated by whatever the hell the professor wants to do, so you can make it a weed-out course if you really want to.
Precisely. But in almost every case, the least-effort choice (because recall: nobody appreciates the work you put into planning a lecture) is to say "Eh, I'll just get the previous professor to give me their notes and I'll change some things around a little bit. I'm not gonna put that much effort into this."
 
Precisely. But in almost every case, the least-effort choice (because recall: nobody appreciates the work you put into planning a lecture) is to say "Eh, I'll just get the previous professor to give me their notes and I'll change some things around a little bit. I'm not gonna put that much effort into this."
While that's more or less true, I did have a few teachers that really meant the world to me and legitimately changed my perspective of the subject material. I had a math professor (and I mean 400 level math) that would trash the examples given in the book and instead create his own variants using fruit and toys and shit. That sounds silly, but it helped tremendously with illustrating what was important to the problem and what wasn't.

It's easy to get caught up in the details of natural vs complex numbers sets, when in reality that was entirely unrelated to the problem.

On the other hand, I've had teachers that REALLY REALLY put in the bare minimum and those classes were miserable as fuck.
 
While that's more or less true, I did have a few teachers that really meant the world to me and legitimately changed my perspective of the subject material. I had a math teacher (and I mean like 400 level math) that would trash the examples given in the book and instead create his own variants using fruit and toys and shit. That sounds silly, but it helped tremendously with illustrating what was important to the problem and what wasn't.

It's easy to get caught up in the details of natural vs complex numbers sets, when in reality that was entirely unrelated to the problem.

On the other hand, I've had teachers that REALLY REALLY put in the bare minimum and those classes were miserable as fuck.
Yeah, it's why those teachers are extra awesome. They really care about their students and the subject material, even to the possible detriment of their own research careers. It sucks that higher education is set up the way that it is.
 
Yeah, it's why those teachers are extra awesome. They really care about their students and the subject material, even to the possible detriment of their own research careers. It sucks that higher education is set up the way that it is.
yeah but at a certain point, it becomes a problem of there only being so many hours in a day. It'd be nice if professors could segregate time better, but that seems like it would start getting into a stickier business model. Also at a certain point, you start overburdening the state/taxpayer.
 
  • Like
Reactions: Yotsubaaa
Disclaimer: I believe the below to be true with a fair amount of certainty, but everything that I typically work with day to day where security is a concern typically eschews HTTP in favor of more secure standards like HTTPS et al so take this with a grain of salt;

HTTP Basic Auth relies on a person's username and password to be transmitted with little more protection than base64 encoding, so any skiddie running Wireshark can easily capture a request and decode those credentials, thus compromising the account. Tokens provide a secondary form of authentication that's only applicable for certain use cases (such as API requests) and thus mitigates the potential damage that can be caused by a MITM or side channel attack, they're typically long strings so they're harder to brute force than most peoples' passwords, and they're only useful within the context of API requests.
The token stuff is just about third-party apps. It's overkill if everything is first-party, meaning you control all the code. In such a case, you enforce same-origin for the javascript that you serve and any smartphone apps you ship are closed source. That way you trust all your REST clients with user credentials (you wrote those clients), and so you stick to basic auth over HTTPS.

However, if you're making a public REST API that does things on behalf of authorised users, then you don't control the code hitting your endpoints, and you shouldn't trust them with user credentials either. Instead, you should get those apps to first authorise themselves on behalf of their users. In some cases, that means the app first redirects the user to your website where they will manually go through an authentication and authorisation process. The user will be told the name of the application and what authorisation it wants (say, it wants to read my tweets, but not send new tweets). The user authenticates (proves I really am the user) and tells your website to authorise the application (allow this application to do stuff on my behalf). Your website then sends the application an authorisation token. The application uses this token to make authorised REST API requests on behalf of the user.

Additional security is typically layered over this, such as third-party applications being given private keys by the website which they then use to sign all API requests. That way, if a malicious party steals a generated authorisation token from an authorised third party app, they still can't make API requests, since they don't have the private key.

This is just OAuth, and it's all pretty old hat. A perceived deficiency is that users have to authenticate to every single website they use, and every website has to be trusted with user credentials. An alternative is to fully separate authentication and authorisation. That means a trusted third-party handles authenticating a user, proving who they are, so they can make authenticated requests to authorise an application to, say, spam twitter.

You now have four different entities involved, and I'd forgive anyone who says this is getting silly.

yeah but at a certain point, it becomes a problem of there only being so many hours in a day. It'd be nice if professors could segregate time better, but that seems like it would start getting into a stickier business model. Also at a certain point, you start overburdening the state/taxpayer.
I doubt it's a problem of funding. Lecturers are pretty cheap, while there's an ever-expanding black hole of administration to suck up public money.
 
Last edited:
  • Informative
Reactions: Jones McCann
I totally agree that a good lecturer can really make or break a student's interest in a subject. With a professor who cares, everything is easier to learn and more enjoyable, and with a professor who doesn't, everything becomes a struggle and an uphill battle. In my university usually the TAs really care and they often put in a lot of work if the professors don't do much for students.

I'm doing a Master's right now and I really do not know where my research interests would lie. I seem to like thinking about basic number theory and algorithms, but I also like programming and having part of code fit together nicely. At least I've positioned myself in a very employable field so I don't think I will have to worry much about the job market. I am not ruling out going into pure CS or math, or becoming a regular programmer, because they seem to be reasonable options.

And about Knuth like GRRM: he's not procrastinating, he's making sure it's right. But who knows how much longer he has to live?
 
  • Feels
Reactions: Yotsubaaa
I totally agree that a good lecturer can really make or break a student's interest in a subject. With a professor who cares, everything is easier to learn and more enjoyable, and with a professor who doesn't, everything becomes a struggle and an uphill battle.

This is so very, very true. When I was in college, I ended up taking a course which covered various aspects of human culture, including music, art, literature, and philosophy. The philosophy portion was taught by a younger teacher who was about two years into his career as an educator and was also working on his thesis at the same time. He'd spend his lectures passionately speaking on the founding figures and concepts of Western philosophy while running back and forth across the length of the whiteboard writing the key points and illustrating how they interconnected, throwing out questions and emphatically reinforcing or correcting the suppositions we'd throw his way. He was so animated and actively engaged in his subject, he'd often sweat through his shirt by the end of the lecture. Pretty sure dude kept like 6 shirts on hand at all times. This was a man who had given himself over entirely to his passion, posessessed by the very spirit of academia. It was a thing of true beauty.

The music portion of that course was taught by a guy who'd spent most of his years teaching music and music theory in one way or another, who loved to share his favorite music with his students and work it into his lectures. For example, I remember listening to "Heroin" by Velvet Underground and going over how the rhythm of the song slowly shifts to mimic the heartbeat of someone anxiously tying off, shooting up, and then drifting off into near catatonia as the drug took effect. He kept a jovial attitude and found ways to share his passion for music with his students in ways that would kindle similar passions in them as well.

In my opinion, I think it's more important for an educator to be passionate about their field and their students, than it is for them to be exceptionally knowledgeable about their subject beyond a certain point. If you have that passion, the rest will surely follow.
 
maybe one day this site will have a CS professor as a user and that will be me :optimistic:
 
  • Feels
Reactions: Yotsubaaa
Back