Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Running promises in sequence and I've lost track of why this code seems to look complicated. First off I've got my nice and simple `sequence` method:

code:

async function sequence (promises) {
    await promises.reduce((acc, curr) => acc.then(curr), Promise.resolve());
}

And I'm using it like so:

code:

await sequence(this.buffer.map(job => queueJob(job, anotherParam)));

// ...

function queueJob (job, anotherParam) {
    return async function () {
        await job(anotherParam);
    };
}

This works perfectly.

I'm just trying to get better at coding. I want to pass that parameter to the job but I can't have the code run until it's the right time, is there a better way to write this?

# ? Feb 14, 2021 13:28

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 08:13

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Nolgthorn posted:

Running promises in sequence and I've lost track of why this code seems to look complicated.

My personal rule is if you're using async/await then you should never use 'then'.

Why not

code:

async function sequence (promises) {
  for (let p of promises) {
    await p();
  }
}

Or you can just do away with sequence and queueJob entirely and do that in place which seems much more readable than the tangle of lambdas you're doing.

code:

for (let job of this.buffer) {
  await job(anotherParam);
}

# ? Feb 14, 2021 18:50

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I heard putting await in a loop was bad practice. There's an eslint rule about it in most shops I've worked, but I agree that's simpler.

# ? Feb 14, 2021 19:29

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I bet that's just to stop people from accidentally running async code sequentially. In this case I'm not trying to make anyone happy so I can even one line it.

code:

// sequence
for (const job of this.buffer) await job(anotherParam);

# ? Feb 14, 2021 19:42

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Nolgthorn posted:

I bet that's just to stop people from accidentally running async code sequentially.

Ah, yeah, that makes sense. But in this case that's literally what you were trying to do, so...

(If you were in an eslint-constrained environment I'd hope you could turn off the linter for this action with a comment directive to the linter and a comment saying "that's the point".)

Edit: https://eslint.org/docs/rules/no-await-in-loop
"[List of reasons you might want to do it sequentially] In such cases it makes sense to use await within a loop and it is recommended to disable the rule via a standard ESLint disable comment."

# ? Feb 14, 2021 19:50

TheFluff: Dec 13, 2006; FRIENDS, LISTEN TO ME
I AM A SEAGULL
OF WEALTH AND TASTE

If you're doing any sort of complex-ish async control flow you should have a look at the async library: http://caolan.github.io/async/v3/

The docs talk about Node-style functions with an err argument, but it also handles actual async functions just as well.

# ? Feb 15, 2021 00:00

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

roomforthetuna posted:

If those protobuffers had been encoded as JSON they'd have just been 2GB over the wire so that wouldn't have helped. Lots of floating point numbers in there, the worst thing to JSON. Even the gross deserialized proto is probably smaller than the JSON encoding would have been (and probably still smaller than the object the JSON 'decodes' to, as well, because the element keys in a deserialized proto are integers not multi-char strings.)

Ah, OK, I thought you were saying the deserializer created so much garbage that wasn't collected fast enough that it'd crash the tab, even with an object graph that otherwise fit in memory.

# ? Feb 15, 2021 17:32

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Munkeymon posted:

Ah, OK, I thought you were saying the deserializer created so much garbage that wasn't collected fast enough that it'd crash the tab, even with an object graph that otherwise fit in memory.

Ah, no, the deserializer didn't create garbage, it just created an unnecessarily oversized data structure. The garbage collection issue came in later when you quick-clicked through stuff so it did five or six of these things in sequence, where the code discards an old one when you start looking at a new one, but the garbage collection doesn't actually free it up for like 60 seconds. The combination of things being oversized *and* garbage collection lagging behind was what led to the crash behavior.

# ? Feb 16, 2021 04:04

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

So my next project is a hotel search type of thing where my idea is you can put in a town or something like that and get returned a lost of hotels. Nothing revolutionary. My question though is this: is like to use this to learn React/ NextJS but I want to ask your guys opinion if something like NextJS is a good platform for a site like that or should I just go pure React? Thanks for your help

# ? Feb 21, 2021 02:52

barkbell: Apr 14, 2006; woof

thats a cool idea

i think it kind of depends on how you want the app to function. do you want the ssr, routing, etc provided by nextjs or do you just need react to build components

# ? Feb 21, 2021 04:10

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

I think React would be nice for component design, but none of its a neccesity except that I can't do conditional rendering with Express

. If that makes sense!

I guess my next step would be the best way to figure out how to do a dynamic type of serach thing with React or NextJS. I see alot of people talk about elasticSearch but that may be a bit excessive for my needs

# ? Feb 21, 2021 04:13

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Empress Brosephine posted:

So my next project is a hotel search type of thing where my idea is you can put in a town or something like that and get returned a lost of hotels. Nothing revolutionary. My question though is this: is like to use this to learn React/ NextJS but I want to ask your guys opinion if something like NextJS is a good platform for a site like that or should I just go pure React? Thanks for your help

If you're doing that kind of thing, please try to avoid doing the all too common lovely thing that sites do these days, where because you make the site out of dynamic components and junk, you forget how internet navigation is supposed to work and lose all the back/forward history navigation, ability to send a link to what you're looking at to a friend, etc.

If you're doing dynamic content, you should make it so the URL always contains all the information to get back to the same content (except for, like, an acknowledgment of an update action or a user-specific shopping cart contents), and make it so when the user navigates within the site, the views they pass through are reflected in the DOM history.

# ? Feb 21, 2021 05:35

Ima Computer: Oct 28, 2007; Stop all the downloading!

Help computer.

roomforthetuna posted:

If you're doing that kind of thing, please try to avoid doing the all too common lovely thing that sites do these days, where because you make the site out of dynamic components and junk, you forget how internet navigation is supposed to work and lose all the back/forward history navigation, ability to send a link to what you're looking at to a friend, etc.

If you're doing dynamic content, you should make it so the URL always contains all the information to get back to the same content (except for, like, an acknowledgment of an update action or a user-specific shopping cart contents), and make it so when the user navigates within the site, the views they pass through are reflected in the DOM history.

Given how with Next.js, you're tied into their routing and data-fetching system, it'd be pretty hard to gently caress it up in the way that you're describing.

# ? Feb 21, 2021 05:58

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

I'm sure I'll find a way :v

I've been spending the night reading up about NextJS some more and how the best method for me to do this is. I'm guessing I'll go back to ol faithful Postgresql to do the data retrieval although I guess I'll have to figure out how to "dynamically" retrieve data from the retrieved data....if that makes sense

# ? Feb 21, 2021 06:04

smackfu: Jun 7, 2004

fireraiser posted:

Given how with Next.js, you're tied into their routing and data-fetching system, it'd be pretty hard to gently caress it up in the way that you're describing.

Still pretty easy to make a button that switches to another view that is not navigable to.

# ? Feb 21, 2021 16:03

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

Jesus I went down quite the rabbit hole today with NextJS and getstaticprops. It seems to be doing what I want though so that's cool. Now I need to learn formik and materialui!

# ? Feb 21, 2021 22:04

OtspIII: Sep 22, 2002

I'm very close to being done adding accounts to my website, but the one remaining step is pretty intimidating--making sure that I'm sending passwords securely from the client to the server. Right now in my dev environment I'm just sending username/password in the body of my POSTs, but that seems like something that should extremely never go live. I've found a few ways of handling things, but am having trouble understanding the context of a lot of what I'm finding. Can I get a sanity check on what's good practice from everyone?

For context: React frontend, Express backend, passport-local for authentication, hosted on AWS. User accounts, email verification, password change, and password reset are all effectively in and working (if there are any other features that really need to be in before launch, I'd appreciate the heads up).

The main thing I'm going to be doing is getting my HTTPS set up. I already have a SSL certificate, but have struggled a bit getting it set up and working in the past--the AWS part is making it hard to visualize exactly where or how it should be done. The research I've done seems to be implying that I need a Load Balancer set up to install it on? I honestly can't tell if that's true or if it's just the one way I was able to find information on. I feel like I'm making things more complex than they need to be, but it also sounds like a Load Balancer might be a good thing to have in general, given that they sound like they help with things like DDoS attacks and I've already had some friction with 4chan. But does a LB even do anything for a relatively small single-server website like mine? I'm honestly still pretty lost in the woods when it comes to server architecture stuff

The other thing I've found that seems more compatible with HTTP transmissions is embedding login data within the authorization header rather than the body, but I have had zero luck getting this to be compatible with passport-local, to the point where I'm wondering if I'm somehow missing the point of how one or the other of them are even meant to be used. Am I missing something?

As a side note, I've been getting a ton of angry messages in the console about how I have password info not held within a form for all this. I've been hand-rolling my server calls, since that honestly seems easier in React than normal form use, but am I missing out on some behind-the-scenes security precautions or something by not using them?

My current plan is to try to set up both my SSL certificate and also get the Auth Header stuff working--does that seem like sufficient safety for password transmission? Or would even just one be enough?

# ? Feb 21, 2021 22:39

go play outside Skyler: Nov 7, 2005

OtspIII posted:

I'm very close to being done adding accounts to my website, but the one remaining step is pretty intimidating--making sure that I'm sending passwords securely from the client to the server. Right now in my dev environment I'm just sending username/password in the body of my POSTs, but that seems like something that should extremely never go live. I've found a few ways of handling things, but am having trouble understanding the context of a lot of what I'm finding. Can I get a sanity check on what's good practice from everyone?

For context: React frontend, Express backend, passport-local for authentication, hosted on AWS. User accounts, email verification, password change, and password reset are all effectively in and working (if there are any other features that really need to be in before launch, I'd appreciate the heads up).

The main thing I'm going to be doing is getting my HTTPS set up. I already have a SSL certificate, but have struggled a bit getting it set up and working in the past--the AWS part is making it hard to visualize exactly where or how it should be done. The research I've done seems to be implying that I need a Load Balancer set up to install it on? I honestly can't tell if that's true or if it's just the one way I was able to find information on. I feel like I'm making things more complex than they need to be, but it also sounds like a Load Balancer might be a good thing to have in general, given that they sound like they help with things like DDoS attacks and I've already had some friction with 4chan. But does a LB even do anything for a relatively small single-server website like mine? I'm honestly still pretty lost in the woods when it comes to server architecture stuff

The other thing I've found that seems more compatible with HTTP transmissions is embedding login data within the authorization header rather than the body, but I have had zero luck getting this to be compatible with passport-local, to the point where I'm wondering if I'm somehow missing the point of how one or the other of them are even meant to be used. Am I missing something?

As a side note, I've been getting a ton of angry messages in the console about how I have password info not held within a form for all this. I've been hand-rolling my server calls, since that honestly seems easier in React than normal form use, but am I missing out on some behind-the-scenes security precautions or something by not using them?

My current plan is to try to set up both my SSL certificate and also get the Auth Header stuff working--does that seem like sufficient safety for password transmission? Or would even just one be enough?

Unless I'm completely out of the loop, you should be fine with just SSL and I honestly don't see why you would need a load balancer for a single server setup. I know some sites hash the password field before sending it out but that has always seemed overkill to me.

For SSL, just use Let's Encrypt. It can fetch a certificate for you automatically and renews them every 3 months. And did I mention it's free and supported by all major browsers without any security warning?

If you really think you need DDoS protection, go with something like Cloudflare. It's super easy to set up though you should check if their free tier is enough for you.

I don't think there's any security implications with using a password field outside a form, except maybe some obscure exploit I'm not aware about, but it's always good practice to wrap all your fields in forms. This enables default behavior that most people are used to (like enter key to submit, better tabbing between fields, better autocomplete, etc). Probably also better for accessibility.

You can always just override the onSubmit event of your form, call e.preventDefault() and return false to make sure the browser doesn't navigate away from the page and that you keep the context.

# ? Feb 21, 2021 23:33

Impotence: Nov 8, 2010; Lipstick Apathy

go play outside Skyler posted:

Unless I'm completely out of the loop, you should be fine with just SSL and I honestly don't see why you would need a load balancer for a single server setup. I know some sites hash the password field before sending it out but that has always seemed overkill to me.

You need the TLS part anyway, otherwise a MITM intercepting it can also just append additional JS to not hash the password or steal the plaintext, nullifying the entire point of it. Same with subresource integrity - they can just replace the JS and replace the nonce/hash.

There are two major types of UI auth, pick one
- traditional sessions, with cookies (normal cookies)
- storing a JWT/refresh token (Authorization: Bearer xxxxxxx usually)

# ? Feb 22, 2021 00:01

TheFluff: Dec 13, 2006; FRIENDS, LISTEN TO ME
I AM A SEAGULL
OF WEALTH AND TASTE

the only thing that separates the http headers of a request from the request body is two newlines. if you're submitting a username/password combo to a login endpoint putting the password in a header makes absolutely no difference vs putting it in a request body. either is fine if you have SSL and haram if you don't (but not having ssl in is just a bad idea in general these days). putting it in the request body is arguably better though; password and login handling is one of those things that should be as boring and conventional as possible and submitting login info via a standard form is about as boring and conventional as it gets.

e: jwt's are absolutely chock full of footguns and should be avoided. if you have to use them, interact with them only though a very well established library and make sure to read the documentation very carefully. for most simple web apps there's not much of a reason to use anything other than plain old session cookies with server side session storage either.

TheFluff fucked around with this message at 00:14 on Feb 22, 2021

# ? Feb 22, 2021 00:09

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

TheFluff posted:

the only thing that separates the http headers of a request from the request body is two newlines. if you're submitting a username/password combo to a login endpoint putting the password in a header makes absolutely no difference vs putting it in a request body. either is fine if you have SSL and haram if you don't (but not having ssl in is just a bad idea in general these days). putting it in the request body is arguably better though; password and login handling is one of those things that should be as boring and conventional as possible and submitting login info via a standard form is about as boring and conventional as it gets.

One argument for putting the password in body rather than request is that request stuff often appears in logs by default, and body generally does not. So if you send your password plaintext-with-ssl, it will likely show up in plaintext logs on the server unless you go out of your way to prevent that, which means if someone gains access to your server they don't even have to take the extra step of cracking the lovely passwords your users chose, or gaining access to the database. (Also logs are slightly more likely to be accidentally remotely accessible in some way than other things.)

# ? Feb 22, 2021 00:17

smackfu: Jun 7, 2004

It�s pretty easy to go around to big �real� websites and see how many of them just send plaintext credentials in their login forms.

For instance, Chase and Citibank have no problem with it. They post username and password as form data. OTOH, Amazon does send an encrypted password.

# ? Feb 22, 2021 00:20

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

smackfu posted:

For instance, Chase and Citibank have no problem with it.

lol. That makes me reconsider my stance on "sending plaintext passwords with ssl is okay". If Citibank does it there's probably something horrifically wrong with it that I don't know about.

# ? Feb 22, 2021 00:22

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

I think if you encrypt it in the db you should be good? Alot of people seem to use https://www.npmjs.com/package/bcrypt which uses plaintext passwords

# ? Feb 22, 2021 00:41

necrotic: Aug 2, 2005; I owe my brother big time for this!

If someone can snoop the payload sending a hashed password would still let them log in, just not know the actual password.

# ? Feb 22, 2021 01:53

Impotence: Nov 8, 2010; Lipstick Apathy

necrotic posted:

If someone can snoop the payload sending a hashed password would still let them log in, just not know the actual password.

I often see these (when not used in innovatively idiotic ways) make a TLS'd call out to retrieve a one time nonce/timestamp/public key, to stop replay attacks and 'salt' it, since the hash will have expired shortly after

# ? Feb 22, 2021 02:16

necrotic: Aug 2, 2005; I owe my brother big time for this!

Biowarfare posted:

I often see these (when not used in innovatively idiotic ways) make a TLS'd call out to retrieve a one time nonce/timestamp/public key, to stop replay attacks and 'salt' it, since the hash will have expired shortly after

Yeah, that's a good way to make it safer if done right. But it's probably overkill in many situations.

# ? Feb 22, 2021 02:59

Impotence: Nov 8, 2010; Lipstick Apathy

my thought re: plaintext+tls is this:

if you are on a not-yours network where TLS is compromised and the compromised certificate is trusted, your device probably is centrally managed/has root certs installed/is being monitored or keylogged by corporate software, or you are not supposed to be logging into personal banking from work anyway

if you are on a secure network and TLS has legitimately been broken by some novel attack, your small dinky app is the least of the world's problems and banks are freaking out over this

if you are on a not-yours network where TLS is compromised and you do not trust the cert (rightfully), then your browser will refuse to load the HSTS-preloaded-from-the-last-time-you-visited-it page at all and prevent you from clicking 'continue anyway'

if someone has legitimately gotten a cert issued for your domain or stolen your key, your server or domain/registrar/dns is probably hacked and you have larger problems

# ? Feb 22, 2021 08:42

Empress Brosephine: Mar 31, 2012; by Jeffrey of YOSPOS

I'm a little confused about NextJS and eventual goals for deployment. I have a very small sqlite db that I use to get data to NextJS via prisma. But in guessing that means I can't use any serverless type of hosting for NextJS even though it's serving staticprops?

I've done soon me reading and saw people mentioning something about turning the sqlite data into api routes which I guess would work since it's mostly static data that just needs a way for a admin to add to it. But I'm not really sure and don't really understand NextJS api routing other than straight up serving JSON. Hoping you all can guide me whether it be suggestions or reccomendationa on a place to host a small sqlite db and the next site

# ? Feb 22, 2021 19:55

SirPablo: May 1, 2004; Pillbug

I'm having issues with CORS, mainly I don't understand it well. Is there really no way to just pull the content of a php script that loads in the browser window fine within a page's JS? Imagine that website.com/data.php returned the text "12345", is the no way to really capture that within a js function?

# ? Feb 23, 2021 06:52

go play outside Skyler: Nov 7, 2005

SirPablo posted:

I'm having issues with CORS, mainly I don't understand it well. Is there really no way to just pull the content of a php script that loads in the browser window fine within a page's JS? Imagine that website.com/data.php returned the text "12345", is the no way to really capture that within a js function?

Unless website.com explicitly allows it, then no, not anymore. If you own website.com, just add the Access-Control-Allow-Origin: * header to the response and you'll be fine.

Another solution, if you really need to scrape something on a server you don't have control of, is to use a proxy server which does the requests for you.

CORS is there to protect people from attacks like logging you in to Facebook from another website. Because your browser has your session information for all websites you visit, the w3c decided to limit the attack surface by blocking all cross-domain requests. This is actually a good thing.

If you're just testing out something for yourself, you can also just disable web security in chrome by starting it with the --disable-web-security command line argument.

# ? Feb 23, 2021 08:34

SirPablo: May 1, 2004; Pillbug

go play outside Skyler posted:

Unless website.com explicitly allows it, then no, not anymore. If you own website.com, just add the Access-Control-Allow-Origin: * header to the response and you'll be fine.

Another solution, if you really need to scrape something on a server you don't have control of, is to use a proxy server which does the requests for you.

CORS is there to protect people from attacks like logging you in to Facebook from another website. Because your browser has your session information for all websites you visit, the w3c decided to limit the attack surface by blocking all cross-domain requests. This is actually a good thing.

If you're just testing out something for yourself, you can also just disable web security in chrome by starting it with the --disable-web-security command line argument.

Thanks. I may just run some python code then to scrape what I need and store it as a static file. (I don't control website.com otherwise I'd probably go the flask route.)

# ? Feb 24, 2021 01:00

OtspIII: Sep 22, 2002

Thanks to everyone with the SSL advice! Trying to get it implemented this time around way much, much easier and has largely been successful (although getting my users to update their bookmarks from http to https is going to be a nightmare).

The relaunch has not been entirely successful, despite everyone's good advice here. I may have created one of the scariest bugs I have ever witnessed.

Somehow (I have no idea how), there is a bug in my code where if any user logs in it logs everybody with the website open into their account simultaneously. I have absolutely no clue what is causing it. I've pulled down the website as I try to diagnose the problem.

# ? Feb 25, 2021 03:34

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

OtspIII posted:

Thanks to everyone with the SSL advice! Trying to get it implemented this time around way much, much easier and has largely been successful (although getting my users to update their bookmarks from http to https is going to be a nightmare).

You can leave a forever-redirect on the http side pretty easily. I don't know what kind of server you're using, but in nginx config it's as simple as

code:

    server {
        listen       80;
        server_name  localhost;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        return 301 [url]https://[/url]$host$request_uri;
    }

Then your users' bookmarks (and external links and etc.) will just continue to work as-is.

# ? Feb 25, 2021 03:39

OtspIII: Sep 22, 2002

roomforthetuna posted:

You can leave a forever-redirect on the http side pretty easily. I don't know what kind of server you're using, but in nginx config it's as simple as
...

This saves me such a headache--thanks!

# ? Feb 25, 2021 06:51

smackfu: Jun 7, 2004

It does feel annoying that CORS came up around the same time that people decided that you shouldn�t host your UI and your APIs on the same server, so everything is cross-origin now.

Also, the amount of time wasted by Chrome�s CORS error that suggests the �no-cors� option is surely immeasurable.

# ? Feb 25, 2021 13:56

Impotence: Nov 8, 2010; Lipstick Apathy

smackfu posted:

It does feel annoying that CORS came up around the same time that people decided that you shouldn�t host your UI and your APIs on the same server, so everything is cross-origin now.

Isn't this half the reason that CORS exists? Because people stopped hosting their UI and API on the same origin?

# ? Feb 25, 2021 14:07

TheFluff: Dec 13, 2006; FRIENDS, LISTEN TO ME
I AM A SEAGULL
OF WEALTH AND TASTE

Biowarfare posted:

Isn't this half the reason that CORS exists? Because people stopped hosting their UI and API on the same origin?

Yes. Before CORS was a thing cross-domain requests in JS were just not possible at all. If you go back and look at really old specs for XMLHTTPRequest they just say that "the XMLHttpRequest interface may be used to allow scripts to programmatically connect to their originating server via HTTP" (emphasis mine).

TheFluff fucked around with this message at 14:30 on Feb 25, 2021

# ? Feb 25, 2021 14:22

smackfu: Jun 7, 2004

Oops, yeah. Mixed up cause and effect.

# ? Feb 25, 2021 14:23

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 08:13

Impotence: Nov 8, 2010; Lipstick Apathy

TheFluff posted:

Yes. Before CORS was a thing cross-domain requests in JS were just not possible at all.

Good old jQuery_jsonp1249805732097({...})

# ? Feb 25, 2021 14:26

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »