Posts not showing up for forestofglory

[toBeOfUse]

Looks like this person is getting these errors: The latest pull request should squeeze some more information out of those [object Object]s, although if they are both Bad Gateway errors then uhhhhhhhhh

[lowercasename]

In the logs it appears that the issue is happening with these two lines:

4|sweet    | (node:8764) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'settings' of undefined
4|sweet    |     at /home/raphael/sweet/app/viewingSweet.js:681:33
4|sweet    |     at Layer.handle [as handle_request] (/home/raphael/sweet/node_modules/express/lib/router/layer.js:95:5)
4|sweet    |     at next (/home/raphael/sweet/node_modules/express/lib/router/route.js:137:13)
4|sweet    |     at Route.dispatch (/home/raphael/sweet/node_modules/express/lib/router/route.js:112:3)
4|sweet    |     at Layer.handle [as handle_request] (/home/raphael/sweet/node_modules/express/lib/router/layer.js:95:5)
4|sweet    |     at /home/raphael/sweet/node_modules/express/lib/router/index.js:281:22
4|sweet    |     at param (/home/raphael/sweet/node_modules/express/lib/router/index.js:354:14)
4|sweet    |     at param (/home/raphael/sweet/node_modules/express/lib/router/index.js:365:14)
4|sweet    |     at param (/home/raphael/sweet/node_modules/express/lib/router/index.js:365:14)
4|sweet    |     at param (/home/raphael/sweet/node_modules/express/lib/router/index.js:365:14)
4|sweet    |     at Function.process_params (/home/raphael/sweet/node_modules/express/lib/router/index.js:410:3)
4|sweet    |     at next (/home/raphael/sweet/node_modules/express/lib/router/index.js:275:10)
4|sweet    |     at /home/raphael/sweet/server.js:124:3
4|sweet    |     at Layer.handle [as handle_request] (/home/raphael/sweet/node_modules/express/lib/router/layer.js:95:5)
4|sweet    |     at trim_prefix (/home/raphael/sweet/node_modules/express/lib/router/index.js:317:13)
4|sweet    |     at /home/raphael/sweet/node_modules/express/lib/router/index.js:284:7
4|sweet    | (node:8764) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 55)
4|sweet    | (node:8764) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'equals' of undefined
4|sweet    |     at myFollowedUserIds.some.following (/home/raphael/sweet/app/viewingSweet.js:894:42)
4|sweet    |     at Array.some (<anonymous>)
4|sweet    |     at displayContext.boostsV2.forEach (/home/raphael/sweet/app/viewingSweet.js:893:43)
4|sweet    |     at CoreMongooseArray.forEach (<anonymous>)
4|sweet    |     at query.then (/home/raphael/sweet/app/viewingSweet.js:887:39)
4|sweet    |     at <anonymous>
4|sweet    |     at process._tickCallback (internal/process/next_tick.js:188:7)
4|sweet    | (node:8764) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 57)

As far as I can make out, forestofglory's req.user does load and it seems to contain the settings object, so I don't know what the heck is happening

[toBeOfUse]

May I ask how you determined that last point? Did you see that req.user was logged correctly and contained the username forestofglory and then an error like the above appeared immediately after?

[lowercasename]

Well, I thought that, but looking through the logs now I can't corroborate it. I thought I saw forestofglory's req.user getting logged correctly followed immediately by the 'settings' error, but in the pm2 log files the error and output logs are separate and neither have timestamps, so.

[toBeOfUse]

May I ask you to give me the paths to these log files so that I can spy on them? It'll look exactly like this, here, except with a different thing given to sendFile

[toBeOfUse]

After an excruciating research session that involved eating 18 m&m cookies while staring at my phone, still parked outside the grocery store, I've determined that a client-side Javascript error like the above can under no circumstances be produced by a server crash like the error logs you posted show, I caused a nearly identical crash deliberately simply by misspelling the word "user" on the line indicated by the error above, so I got the same "Cannot read property 'settings' of undefined" error, but in my browser's network panel, the request was simply shown as "pending" indefinitely, there was never a result of "bad gateway" or any kind of Javascript error like this user got. Which kind of makes sense, I've never seen that in crashes before.

Therefore, I believe that the client side error that I put at the top of this page and the server side crash caused by the inability to use req.user are both just symptoms of the same underlying HTTP issue with the request to showposts. The server must be receiving cookies initially in order to see that the user is logged in and should therefore be shown the home feed-containing page, but the request to showposts is apparently not accompanied by the authenticating cookie or else req.user would be loaded and accessible in that code, and the potential response from showposts must also be being blocked by "something" on the user's end or they wouldn't be getting the bad gateway and script errors shown in the client-side error log. That's definitely this user there in that log, too, I checked the user id there against the one in the HTML of their profile page.

According to MDN, the HyperText Transfer Protocol (HTTP) 502 Bad Gateway server error response code indicates that the server, while acting as a gateway or proxy, received an invalid response from the upstream server. SO. I don't know what that means.

[toBeOfUse]

^wrong button

[toBeOfUse]

Well I can't sleep like at all, so let me write an extremely boring comment explaining some of the gibberish I was rendering up above. Normally, when sending an HTTP request to sweet.sh, one's browser also sends the cookies previously created by sweet.sh. In our case, the only cookie we have to worry about is the one that passport set, which contains an authentication token. When a request is made to sweet.sh, and that cookie is sent with it, passport uses the authentication token to identify the logged-in user sending the request, and sets req.user equal to that user's data (that last part is done in the deserializeUser function in passport.js.)

There is a slight problem that can occur with this simple model, though. If I own mitchhacksyourshit.com, I can put code on a page there that sends a request to sweet.sh/createpost that confesses to horrible crimes and causes all of your followers to unfollow you. I post the link on sweet like "hey guys check out this cute dog: mitchhacksyourshit.com/issuehorsearsoncrimesconfession" and soon after I have all of my mutuals all to myself.

To prevent this, browsers implement the same-origin policy, which means a cookie-containing request can't generally be sent from one origin (mitchhacksyourshit.com) to another (sweet.sh.) (That's simplified, I guess there are a few different factors that determine whether any given cross-origin request is allowed, and they vary from browser to browser and browser version to browser version.) There are also a bunch of boring addenda about for example how errors caused by different-origin scripts can't be seen by window.onerror unless they're embedded with the crossorigin attribute, like what's currently keeping us from getting detailed client-side error reporting from a couple of our embedded scripts, their errors are just showing up as "Script error" right now.

(Allowing for some leeway here are CORS (cross-origin resource sharing) headers. If I owned sweet.sh and thought that mitchhacksyourshit.com was a reputable website that just wanted to help users make posts, I could set a CORS header that allowed its post requests to make it to sweet.sh intact. I could also set some CORS headers to * and cause browsers to completely ignore the same-origin policy when making requests to my site, although that's not important to us right now (we don't want to do that.))

Anyway, infinite-scroll.js is kind of from a different origin than sweet.sh because we're linking it in from a cdn, and although most browsers notice that sweet.sh is purposefully embedding it and take that as evidence that it's fully allowed to make requests to sweet.sh, including with the authentication cookie, I could imagine some super strict browser considering this a violation of its same-origin policy and causing forestofglory's problem, which is why I have a vague feeling that it would help if we hosted it locally.

[toBeOfUse]

(Another note on the above: users can always subvert security policies and spoof origins and send us whatever HTTP requests (like get and post) that they want, for example through their browser's command line, or just by using a cracked browser that doesn't implement a same-origin policy, although of course they can't really pretend to be another user bc they can't get that user's authentication token. Anyway, that's why we have to validate all incoming requests, always, generally by looking at req.user (again, which passport loads based on the authentication token that's sent) and seeing if that user is authorized in making the request that they're making.)

[toBeOfUse]

Ok I deleted most of the gibberish anyway. The only other thing was: based on the fact that this problem occurred on the user's computer and phone, it might just be some problem with a proxy setup that they have on their home network (Bad Gateway generally indicates some kind of proxy is involved, I guess) and also I think I'm going to make infinite-scroll.js locally hosted in the cleanup pull request, just based on my vague suspicion.

[toBeOfUse]

Sorry for writing my comments here so un-organizedly originally! Feel free to question me on any of this and I'll try to find the answer, you're not dumb, if you don't understand something here than I'm explaining it badly. I know I'm like... the worst version of myself when I'm working on a project like this. Follow me on Instagram maybe

[lowercasename]

Hi! Oh wow you've done a lot of work, I have limited internet here but all this makes sense to me and I can push something to the server from the PRs if it'll help your investigations, also, go to bed on time and drink plenty of water

[toBeOfUse]

thank

On Fri, 28 Jun 2019, 16:33 Raphael, notifications@github.com wrote:

Hi! Oh wow you've done a lot of work, I have limited internet here but all this makes sense to me and I can push something to the server from the PRs if it'll help your investigations, also, go to bed on time and drink plenty of water

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/lowercasename/sweet/issues/86?email_source=notifications&email_token=AL3NDOVRO4OZKYIOKQY6UR3P4ZYSJA5CNFSM4H2XNKEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY3DFFI#issuecomment-506868373, or mute the thread https://github.com/notifications/unsubscribe-auth/AL3NDOQ543PFIAPB2FF7ZGDP4ZYSJANCNFSM4H2XNKEA .