Journalish - Your own Journal(ish)

Journalish

So I wanted to make a Journal app after one of my previous teachers decided that she wanted to go through my “rude” journal. So I created this.

You need a password to enter it. Later, I’m hoping to add sessions to automatically log out.

The repo is here and currently, it has no client yet (I kind of need help with the client). The API is in API.md.

You can use SQLite, Redis, MongoDB, PostgreSQL, MySQL, or MariaDB to store your notes.

3 Likes

I’d love to help with the client!

  • views/index.html is not checked in
  • could move index.html to /public if it’s going to be sent by a bare sendFile with no templating
  • “All FIelds are Required” FI -> Fi
  • is this res ... .json('{"success": ... }') redundant? I think I saw other examples do it like res.json({success: ...})
  • consider using constant-time comparison when checking the password
  • if this is specialized for deployment on Glitch, it might be nicer to put the password in .env instead of config.json
  • maybe move password checking to a middleware function, so that there aren’t so many repetitions of a rather critical routine. this would help the maintainability of the project, because you would otherwise have to be very careful about updating each occurrence
  • storing titles and bodies in separate stores–this leads to complications with creating/deleting these entries non-atomic. you’d additionally have to deal with the case when one of the two operations fails
  • fire-and-forget promises: invocations like find(req.query.id); support the happy path of working correctly and sending a response, but there’s no error handling. in the /create and /delete routes, the handler sends a ‘success’ response without even waiting for the database. maybe you’ll be lucky and never encounter any problems. but if there is a problem, you’ll be a lot worse off in debugging it due to this
  • string interpolation into JSON '{ ... "result": "' + id + '"}' – although id is generated internally, it’s just risky to get in the habit of doing this. because what’s next, concatenating content in HTML code?
  • no check for req.query.body in /create? dunno if this is intentional.
  • passwords in the URL parameters? am I reading this right? how hard would it be to avoid this? maybe I’m just superstitious, but I fear that some software is just not very careful about data stored in a URL
3 Likes

I’m going to try to answer everything that you said, If I missed something, I’m sorry
Points 1 & 2: I accidentally forgot to set it to res.location(302, journalish.github.com) for the time being
Point 3: Thanks, I’ll fix that
Point 4: I don’t know what you mean
Point 5: Ok
Point 6: It’s not just for Glitch
Pont 7: Ok, I’ll try that
8: I don’t really have another solution
9: Ok, I’ll make sure to add error handling
10: ???
11: Intentional. In my old memo app, you just needed a title or a body. I’ll try to fix this
12: I’ll also try to fix this

Thanks for bringing up these things

3 Likes

hi, thanks for reading through all that. sorry I didn’t number everything in that last post :woman_facepalming:

for point 4: I’m looking at the express API https://expressjs.com/en/api.html#res.json and it says you would pass res.json an object, and it internally does JSON.stringify to convert it to a string and sends it to the client. in your program, it passes res.json a JSON string, as if you were calling JSON.stringify yourself.

for point 10: what would happen if id contained a " character? I know your program is written in such a way that id only ever contains strings of a certain form, and you may happen to know that this randstring library would never output a double quote. but the point in thinking of what if isn’t because we doubt that. it takes us on a path where (1) we find a solution that would work in the more general case, where id could contain contain a "; (2) we analyze the pros and cons of this more general solution and this string concatenation solution; and (3) we find the analysis so overwhelming we take one solution entirely out of our repertoire

4: I didn’t use res.json because it kept sending {\"key"\: \"value"\}, I didn’t know how to fix it, sorry.

10: By default, It’s supposed to only send numeric characters, But, I’m not so sure what would happen either

Also, another thing is, what if really anyone tries to block the connection?