What dev topic do you think you should understand, but don't?

Ooh that is a great site for comparison! Thanks for the share!

Sweet! So basically there are three types of software licenses, at least as I see it.

1. Commercial licenses
   These are your standard "pay for it, use it" licenses. They can have lots of different conditions and are as numerous as the companies that use them.

2. Open, but ideological
   These licenses open the source and the use of software, but with extra protections around derivatives or use cases. All GPL variants fall into this - the require any software that uses GPL code to also be GPL licensed. It's a literal viral license - using GPL code makes your code GPL.

3. Fully open
   These licenses exist to share software far and wide, with very little restrictions. I personally believe these to be the only true "free" software licenses. Social cost is still a cost! MIT, WTFPL, BSD, and a lot of others fall into this. Often the protections in these are around copyright (you can't just take this software and claim you made it) and legal protections for misuse (if you use this software and it causes damage to your business, you can't sue the creator). Apache also falls into this category for me, but includes protection for patents.

There are tons of variants on these licenses, for pretty much anything you want to do. For some real world context, here is a great piece on the React license changing from BSD+Patents to MIT.

My recommendation is this: unless you have a great reason to use something else, you probably want MIT. It's the most permissive, has good protections, and is widely used.

If you want to see what other licenses do, check out TL;DRLegal. It is a great site for all things TOS, license, EULA's and TOS.

Hope this helps!

I find the hardest part about authentication is that somebody will use a method, and then somebody else will tell you that that method is incredibly insecure.

Like, lots of people do stuff others deem "incredibly insecure". It can be really hard to settle on any understanding of what appropriate levels of security are in this space.

Services and top libraries tend to give some direction, but any time you want to change your approach or try something new, you're met with a lot of competing beliefs.

What does it mean to be performant?

This is the million dollar question. If you can't answer it maybe the system is already performant enough. You'll know if the performance is not satisfactory (user frustration in case the system has a UI or slow processing time to obtain a response from an inquiry).

How do you know if it can scale well?

You measure it, you'll never know with 100% certainty but, for example, if you have a 1000 users per minute and your system is at peak CPU most of that time and the RAM baseline isn't great either, you know it's not going to perform well if you double that.

I think vaguely in my current project (2 years) we're now starting to look at benchmarking our current database (x1) and x2, x5, and x10 by making those data sets and letting JMeter run loose on all our endpoints. But it's not like we have a goal of being able to get back all the responses in under 500ms with the x10 set.

You also obviously need to be realistic, especially if you control how many users use your system (if it has a subscription model and you know the subscription rate). Yeah, one day you might be hit with 10x lots of traffic but if you optimize for 2, 3, 4 or 5x you are already learning something about your system.

I don't know if this system we are talking about is a webapp or something else but you need to figure out the correct metrics and decide what's acceptable for you. This is a good intro:

The case for performance (Part 1)

Joshua Nelson ✨

#javascript#performance#metrics

Aside from hearing something like OWASP once, I have no clue how to check that an app is secure against common attacks or how to prevent that.

If you're using a decent ORM you already protected by a few of those vulnerabilities (mainly sql injection).

The OWASP Top Ten PDF is the most boring thing ever to read but you're lucky (😂): Troy Hunt, a security specialist and the author of have i been pwned? has a 1-hour course on the OWASP top 10. His blog, troyhunt.com, is also quite interesting.

I haven't watched it but Hunt knows his stuff.

Also check this "checklist" out:

Web Developer Security Checklist V2

Michael O'Brien

#security#aws#webdev#devops

Hi Max,

I'll try to give you an answer.

A cookie is just a particular type of HTTP header: Cookie:. Cookie were invented to store a little bit of information sent back and forth between stateless clients and servers (HTTP holds no state).

So, now you have this header where you can store stuff into: the list of items you added to your cart, a username, whatever. Cookies have no actual knowledge of what they carry.

In addition to the actual data, a cookie has a bunch of optional metadata (attributes): expiration date, path, domain, security, http only and others.

There's a bit of a misplaced naming convention because technically a "session cookie" is a cookie that dies after the user has finished their own session (closed the tab or the window of the browser). These cookies do not have an expiration date, which signals the browser to delete them after the user's session is finished.

Unfortunately, because we're programmers and we're trash at naming things, other people started using the words "session cookie" also to identify the particular set of value and attributes to recognize a user's session against a webserver in a span of time. To make it simple: that thing that keeps you identified to a single website even when you close the browser, turn off the computer, come back two days later, reopen the browser and voila, you're still known by the server.

This is not magic, it's just using a couple of tricks to overcome the fact that HTTP is stateless.

Let's go over the simplest scenario, using a session cookie to login. You go over website.com for the first time, type username and password, hit submit and then the server (other than checking the credentials) does one particular thing. Adds the following header to their HTTP response:

Set-Cookie: token=supersecret; Expires=Wed, 19 Nov 2019 12:00:00 GMT

What this tells the browser is the following: store a cookie, for website.com, with these values (token=supersecret) until a year from now.

In addition to sending the cookie to the client, stores somewhere (usually a database, but not necessarily) a sort of key value to know that this particular token is associated to the newly identified user.

Then you go about your business. The nextime you go to website.com the browser checks its storage, see it has a cookie, sends it with the HTTP request. The server verifies it's still valid and then lets you in.

Once the cookie expires, the server will bounce you :)

The identification, the storage of the token on the client and the identifying info on the server is what constitutes the concept of "session".

This is a way to build state on top of a stateless protocol.

I'll try to answer your questions now:

Is the session data stored in the session or the cookie?

You can, but IMHO you shouldn't store the actual session data in the cookie, you should store an identifier and the data in a temporary store (a cache) or a persistent one (a database)

Is it fetched from the server every time you need it

It's the client that keeps sending to the server the cookie everytime you hit a URL. Keep in mind that HTTP is stateless, so the server has no idea that you are the same user that asked for a page two seconds ago.

Does the session expire?

So, if the session is stored in the cookie, it will disappear when the cookie expires. If you store it on the server in a time limited key in a cache, the cache server will remove it for you. If you store it in a database, make sure your server framework has the ability to clean up stale sessions.

Does the cookie expire?

Yes

How are cookies shared securely?

The cookie specification has at least a couple of countermeasures: Secure and HttpOnly. The first one means the cookie can only be transmitted over HTTPS, the second one will make the cookie invisible to JavaScript. A newer option is to set the SameSite attribute to prevent cross site attempts to steal the cookie

Hope this helps! Let me know if you have any more questions!

You can make each callback function return the function before it - like this:

const topLevelData = funcWithCallback(someVar, () => {
  return anotherFuncWithCallback(someOtherVar, () => {
    return yetAnotherFuncWithCallback(aDifferentVar, () => {
      return "result";
    });
  });
});

And then those functions would need to return their callback:

function yetAnotherFuncWithCallback(data, callback) {
  doSomethingWithData(data);
  return callback();
}

Then you should have it outside of the callbacks!