Currently, when building the website (both prod and dev mode), we are using npm install and regenerating a new package-lock.json.
There is no point of pushing the package-lock.json on the repo if we override them when building.
We should change all the occurrences of npm install by npm ci (clean install) which use the current package-lock.json instead of overriding it.
Hence, we can lock a version of a package we use if needed, and we won't have any version issue when building the app at different places.

Context:
The blog as it has been released on v0.1.0 seems really vulnerable to DB filling to me.

Problem:
I didn't tried it but it shouldn't be impossible for anyone to write a simple python script submitting millions of new articles filling the iScsc database.
This also brought to my attention that at the moment nothing forbid a non iScsc member to create an account and write a blog... not that we want to be sectarian but that also means that anyone can write anything, potentially non-related subject or worse...

Solution:
First of all we should at least add a Captcha or something to prevent a bot from being able to submit an article.
Additionally, I would like to let only iScsc member write article for the time being, for example with a iScsc badge added to the profile page, which would fit nicely I think to the v0.2.0
Later we should maybe add a review step from iScsc member for articles submitted by non-members, and limit pending articles to a reasonable number, once again to prevent DB filling.

Now that the v0.0.1 has been release, I would like to work on the profile page of each user.

Indeed, I want to move the management of the blogs writen by users to this profile page. Hence, the root page of the blog will just show the articles, whereas users would be able to create, modify and delete posts on their profile page.

This issue will propose some changes regarding the article management on the profile pages.

Here is an unordered list of the new features:

• Create a new page in the frontend to display and edit user information - frontend
• Add article management page: users can see, edit and delete their own article from here - frontend
• Extend API to modify user information - backend
• Extend API to modify articles - backend
• Add new user information like avatar, short bio - backend/database

In this issue, I would like to highlight the fact that the workflow of this project is not automated yet, and that a lot of tasks are still done by hand. To cite some of them:

• Sharing of .env in a secure way to authorized developers (cf #29)
• Deployement of the website (cf #20)
• Test integration (cf #11)
• #64

Moreover, we can imagine a deployment of the website soon and this will induce a major change on the dev workflow. For example, developers mustn't play anymore with the official database used for the deployed version.

In order to avoid these issues, I would like to propose some basic scripts to make the development process easier. A first PR with some changes in how to deploy the website for dev purpose will be open soon.

Context:
I was just wondering, is the website vulnerable to CSRF?

Problem:
Does this attack scenario would work:

• make sure the author of a targeted article is logged on iscsc.fr
• send him a crafted URL requesting the deletion of his article OR a URL to complete the article writing form
• make him click on the link

Nothing is done in the source code to protect the blog against these attacks but maybe the framework used do it already?

Other:
Another minor question, how long is the website cookie valid?

I recently discovered a bug in the iscsc.fr app related with #2
I didn't deepen, but after a successful authentication, the backend sends back to client a token, with username, email and JWT
{"email":"[email protected]","username":"HelloWorld","token":"F4KEJWT.NOTREAL.TEST"}
Of course, you can control the value of this token inside you browser and modify the email, and username.

So note for my future self (or future developers on this website), WE MUST NOT TEST THE USERNAME OR THE EMAIL WITH THESE VALUES, BUT WITH THE ONES DECODED FROM THE JWT, ONLY IN THE BACKEND.
I don't think there is any security implications at the moment, but I wanted to highlight it somewhere.
If somebody wants to test what can be done with this, are propose a correction to avoid future bugs, let me know.

This is an old bug that hasn't been corrected yet

Problem:
This message appears when trying to Sign Up with a username (or email) that already exists in the database.

We could replace it with a more User Friendly message

Steps to reproduce:

• click Sign Up
• fill with a junk email address: "[email protected]"
• fill with YOUR username
• fill with a valid password like: "Aaaaaa1!"
• click submit

This is absolutely the same with the email address

Linked to #10

The goal is to add a proper logger and logging in the whole code, instead of using on console.log.
EDIT:
We must add a proper logger object with:

• timestamp information
• separate loggers for different part of the code
• logging to different outputs (stdout and log files) allowing to properly separate log types
• log levels
• ...please add what I forgot!

I heard of signale-logger and winston but I don't know which is best!

When clicking on the Go back button in the browser (Firefox) in the login page, the page remains the same.

Steps to reproduce :

• "Write my own article" (you must be logged off your account)
• click on the Go back button in your browser

This does not happen when I click on the blog title in the same situation.

Browser used: Mozilla Firefox 106.0.5

Problem:
2 flaws were introduced by #92 (that should have been detected in review ooops):

• the database isn't persistent: the wrong folder is mount
  we use a bitnami/mongodb image and according to the documentation the
  volume to mount is /bitnami/mongodb not /data/db
• the backend can't reach the DB if DB_PORT != 27017 which kind of destroy the interest of having a config var...

Solution:
I found a solution to both of these problems in the documentation linked above (the right volume to mount and the MONGODB_EXTRA_FLAGS var to declare the right port) and I'll soon open a PR

Additionally the image 4.4 is quite old... we should agree on a newer version, I don't like using latest (but I'll use it if you have good arguments)
@atxr @amtoine

Trying to upload an article that is too big causes an error in the backend; I produced this error by trying to upload a 64ko file as a markdown article.

The preview worked fine, but pressing the "Add article" button creates the following error (see end of message) in the backend.
From the user's perspective, nothing happened as no new article is created, and no error is reported.

Details:

• OS: Windows 10
• npm version: 8.19.1
• node version: 18.9.1

Error message:

PayloadTooLargeError: request entity too large
    at readStream (C:\Users\*****\Documents\repo\site\backend\node_modules\raw-body\index.js:156:17)
    at getRawBody (C:\Users\*****\Documents\repo\site\backend\node_modules\raw-body\index.js:109:12)
    at read (C:\Users\*****\Documents\repo\site\backend\node_modules\body-parser\lib\read.js:79:3)
    at jsonParser (C:\Users\*****\Documents\repo\site\backend\node_modules\body-parser\lib\types\json.js:135:5)
    at Layer.handle [as handle_request] (C:\Users\*****\Documents\repo\site\backend\node_modules\express\lib\router\layer.js:95:5)
    at trim_prefix (C:\Users\*****\Documents\repo\site\backend\node_modules\express\lib\router\index.js:328:13)
    at C:\Users\*****\Documents\repo\site\backend\node_modules\express\lib\router\index.js:286:9
    at Function.process_params (C:\Users\*****\Documents\repo\site\backend\node_modules\express\lib\router\index.js:346:12)
    at next (C:\Users\*****\Documents\repo\site\backend\node_modules\express\lib\router\index.js:280:10)
    at expressInit (C:\Users\*****\Documents\repo\site\backend\node_modules\express\lib\middleware\init.js:40:5)

Title. Going to the link https://iscsc.fr/blog/create-article put the user back on the main blog page https://iscsc.fr/blog/

When deploying the website, docker proposed me this:

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them

We should probably give Snyk a try!
Here is the website

I'd like to see the GitHub logo with a link to the repo right next to the iScsc title on the home (currently /blog) page

This should be quite simple as it is only frontend side, I'll then assign the good first issue label 👍
Tell me what you think of the idea!

Here is a non-exhaustive list of things we must implement:
(heavily based on the current expressJS backend, some things might become useless or implemented differently with flask)

• #110
• Implement a UserController
• #108
• #111
  The controllers might embed this object
• #109
• Write pytest test suite and a corresponding github Action

Problem

The website has been deployed, and I was trying to visit a blog post from amtoine (the first actually) by clicking on an URL

Step to reproduce:

• Try to access to https://iscsc.fr/blog/637669b524bc362fff7a2b23
• go to https://iscsc.fr and choose the blog post from amtoine - 2022-11-17T17:04:53.781Z
• the URL are the same but accessing with the URL seems to fail

in ./backend/package.json you can find:

  "author": "Alexandre Tullot",
  "license": "ISC",

I think that @atxr deserves that author field but license isn't the right now that we've choose GPL3 or am I wrong?

    No else here?

Originally posted by @ctmbl in #2 (comment)

Context

Right now, when creating an article it is directly published and there isn't any step between.

Problem

In multiple situations this could upset the user:

• I start writing a blog and don't have time to finish it --> I'd need a "Draft" state
• I'd like to "hide" temporarily my blog post because I need to edit it --> I'd need a "Draft" or "Paused" or "Private" state
• I no longer want to publicly own this article but I'd like to keep it for my own use for a moment (or indefinitely this could be debated) --> I'd need a "Private" state

Solution I'd like

We should change the article storage scheme to add at list one of the state I introduced above.
We should filter the list of article shown on the main page to show only:

• "Public" articles
• "<other state>" and owned by the logged user

The state of such articles should be clearly displayed with a colored tag near its name for example, maybe with the mention "only you can see this".
The user should find (ofc) these articles on its future profile page introduced by #12

Last point

I'd like to add this issue to the 0.2.0 milestone!

Pretty clear, when clicking the Delete button on a blog post I owned, no confirmation is asked, and I'm pretty sure that in the backend it is suppressed rather than archived so we should definitely add a confirmation pop up! (even a basic one)

EDIT: PS: the same remark applies for the Add article button when writing one!

simply go to https://iscsc.fr/blog/637669b524bc362fff7a2b23 😉

😤 is rendered as :triumph:
👋 is rendered as :wave:
🤩 is rendered as :star_struck:

Context

#20 and #34 introduced containerization in production mode, #86 will extend it to development mode.
However the processes are run as root in the containers, one could argue that even if an attacker manages to exploit the website and get a shell (it would then be a root shell) they would still be in the container, so separated from the actual server.
But what if they manages to docker escape? or what if they simply installs parasite processes, for example to spy on users or exploit our server computation resources? One could theoretically could do that from within the container.
This issue arises to me when working on the mongodb image/container for #95 and I read this:
comparison from bitnami about root/non-root containers.

Anyway running containers as root is still a bad habit.

Problem

Run an exposed to the internet process as root is a bad security habit, even in a container.

Solution

We should refactor both dev and production mode (meaning environment so Dockerfiles and docker-compose files) to run processes as unprivileged users.
We could let the development environment as is but in order to detect bugs as early as possible, development and production environment (as well as test env) should be as similar as possible. So I'd prefer to refactor both!

We could encounter issues with mounted volume.

Recently, @ctmbl noticed in the backend logs this error:

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
    at new NodeError (node:internal/errors:393:5)
    at ServerResponse.setHeader (node:_http_outgoing:644:11)
    at ServerResponse.header (/backend/node_modules/express/lib/response.js:794:10)
    at ServerResponse.send (/backend/node_modules/express/lib/response.js:174:12)
    at ServerResponse.json (/backend/node_modules/express/lib/response.js:278:15)
    at getByAuthor (/backend/controllers/articleController.js:23:21)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'ERR_HTTP_HEADERS_SENT'
}

    This PR also arises an important question: in such cases where we found a vulnerability and want to patch it, shouldn't we release a `v0.1.1` rapidly to patch the vulnerability on the real website or should we wait for `v0.2.0`.

In the case we want to release v0.1.1 should we:

• A: merge this PR in main and release previously merged PRs (from v0.1.0) with it
• B: merge on a specific branch (let's say released) which is based on v0.1.0 and then merge release into main?

Following git log --oneline ... format:
A:

* (main, v0.1.1) this PR
* commit
* commit
* (v0.1.0) Bump to version 0.1.0

B:

* (main) Merged with `released`
|\
* | commit
* | commit
| * (released, v0.1.1) this PR
|/
* (v0.1.0) Bump to version 0.1.0

Originally posted by @ctmbl in #51 (comment)

The title and the icon of the iscsc.fr website, shown in the tab of your browser, are still the default ones.

The Log In and the Sign Up headings in their forms are too small for their place.
In Login.js and Signup.js they can be moved to a <h1> tag.
I would be happy if you assign this issue to me

cc/ @atxr

about the question in #78 and the change request in #81.

@atxr, could you add a very simple CI in .github/workflows/ to format check the format of the code base with prettier? 😋

EDIT: the CI should fail if the format is not good. the CI should not try to commit on top of a PR branch if the format is bad.

Currently blocked by #12

Problem

There is no mean, at the time, to review blog posts, for example to fix typos, add/ask for additional information or warn about dead links.
We should also be able to report blog posts.

Some Solutions

Here is a list (from the simplest to the most complex ones) of solutions I imagined:

• a simple comment section below the post (this is for another issue but the author could be notified)
• a mean to send private messages to/email the author, with or without some embedding to highlight/show the diff one would like
• a more complex workflow where, after submitting a post an author, the post is in Review state (analogous to #75) and the author must wait for, designated or not, reviewers approval (same as GitHub PRs or Root-Me solution submitting)
• some other I didn't think of ??

Problem:
#1 and #2 introduce the first website.
And finding the first bugs should make us think about creating testing procedures and/or automatic tests.

Idea:
The goal is to at least make a list of test procedures to be able to check that main features still work fine after each PR.
We could also implement regression tests.
The ultimate goal would of course to have a test pipeline using GitHub actions but let's start with the basis.

Challenges:

• I don't know any test framework for Node/react etc
• I don't have experience in these framework neither...
• what should be tested? How to evaluate tests coverage?
• Should we test the backend and frontend separated, together or both?

as introduced in #29, a new script has been added to the source to easily share the environment secrets with other developers using pgp keys and archives.

the current script

the script is used as follows:

bash> ./scripts/gpg-share.sh <file-to-share> <user1> <user2> ...

or, when multi-words users have to be used or to save the list of people in a file

bash> USER_FILE="users.txt" ./scripts/gpg-share.sh <file-to-share>

with the following users

# users.txt
first user
another-one
last user

this is arguably not the best experience...

idea of feature

during the review of #29, an idea has been introduced: using flags

• a --user (-u) flag to add one user from the standard input
• a --users (-U) flag to add additional users from a file

this will lead to the following usage:

# users.txt
additional user

bash> ./scripts/gpg-share.sh -u "first user" -u "user" -u "last one" -U users.txt

or

bash> ./scripts/gpg-share.sh \
    -u "first user" \
    -u "user" \
    -u "last one" \
    -U users.txt

much better isn't it? 😋

we could also add --help (-h) to see the help of the script and why not --check-keyring (-k) to check to keyring of the user calling the script and make sure everything is ok 👌

#20 added containerization to deploy the website in production mode.

I would like to extend it to development mode in order to:

• not mess with the host (developer)'s environment
• solve env issues for Windows developer
• homogenize modes
• create a single script to run either development or production mode, transparently for the user
• solve potential version/environment problem for developer working on different machines

Would be nice to have feedback on this!

I'm currently working on so I'm assigning it to myself

Currently, the documentation doesn't mention the node and npm version used.
We should add the following information in the repo:

• node 19
• npm 8.19.2

Title is self explanatory. Right-click -> "Open in a new tab/window" displays a blank page instead of the article.
Issue happens on both Chrome Version 105/106 and Firefox Version 105 on Windows 10.

Details:

• OS: Windows 10
• npm version: 8.19.1
• node version: 18.9.1

the README is quite long now 😮
i wanted to have a look, to remind me how to test the website locally but i have some trouble finding my way in it...

i think the README might benefit from one or more of the following

• section numbers
• some emojis around section titles
• maybe a table content at the top?

cheers 😋

Thank you for your warm welcome :)
I have just sent a PR. I added section numbers and a table of contents. I also corrected some spelling and punctuation errors.
You asked about clarity, and I have a few suggestions.
First, I would suggest rephrasing a couple of sentences to make them sound more straightforward. For example, “The author assigned to the article will be the name of the authenticated user.” could be put as “Your username will appear as the author of the article.”
Second, I think the deployment section could be structured a bit better. It’s a list of steps, but when you scroll through it, it is not clear. You need to read the details to understand what the paragraph is about. My suggestions would be to: change heading titles to start with a verb, use numbered lists, put prerequisites before the task description, and remove quote formatting.
Below is an example of what I mean. As it’s not what you asked, I created a separate branch in my forked repository to work on additional changes. For me, it’s always an exercise. Later I can send another PR, and you can see if it is something you’d like to apply.

2.2 Production mode

The production mode allows to deploy the application on the server. To use it, you will need:

• docker
• docker-compose

a) Set up environment variables(.env file)

Before deploying the application, you need to set the environment variables as for development mode.

• From the root directory of the repository, do the following:

cp .env.example .env.production

b) Create SSL certificates

To set up HTTPS, you will need valid SSL certificates.

• If you deploy the app for the first time, follow these instructions:

1. Comment or delete the whole server section about 443 in the nginx/nginx.conf.template file.

- server {
- listen 443 default_server ssl http2;
- ...
- }

This step is required because the certificates don't exist yet, so they cannot be loaded in the nginx configuration.

Originally posted by @OlaPom in #79 (comment)

Currently the website is using HTTP because it was easier to setup at the beginning.
But for obvious security reason, HTTPS must be setup to encrypt the traffic.

#20, #27 and #29 introduced some scripts to the source, nginx/run_nginx.sh, bump.sh and scripts/gpg-share.sh respectively

i'm wondering if we could place them in a single location 🤔

proposition

i think ./scripts/ would be the best
bump.sh seems trivial to move from the root to ./scripts/
i do not know if that's possible with nginx/run_nginx.sh, if not, that's ok 😋

list the scripts

nushell> ls **/*.sh | get name
╭───┬──────────────────────╮
│ 0 │ bump.sh              │
│ 1 │ nginx/run_nginx.sh   │
│ 2 │ scripts/gpg-share.sh │
╰───┴──────────────────────╯

we need to add ngix and docker compose to the tree in the README

Context:
The #2 PR from @atxr has introduced User Authentication to our website: a mandatory feature to develop other services around the website. However this PR also brought many security concerns.. and we, as students, aren't fully capable of designing an entirely safe website, even a small one, despite all our interest towards cyber-security. At least that's what I think.

Problem:
Even with our best effort we can't design a safe website.

Solution:
I then want to propose a complementary solution, that I think is also widely used in the industry and is quite an interesting challenge.
Because we can't guarantee that the website is safe we could monitor the traffic and log it. That would allow to detect as early as possible breaking-in attempts.
I don't know what kind of security and monitoring the current website and framework offers (defense against brute-forcing, automatic log to a file etc) but I'm interested in looking deeper into the subject!

Currently, all the components on the website are designed with raw CSS.
This is not very efficient, and because none of us is a web designer, this is also hard to get a clean result.

Many "design libraries" exist to make this task easier. They propose some basic components, easy to use and customizable, to avoid starting from scratch the web design.
MUI is one of the most famous, and often used with React.
I would like to include it in the frontend to make this task easier.

Also, this is a great time to think about a new design for the website if needed.
By new design, I'm mostly thinking about a new color scheme/font, and a new layout for the website.
Feel free to propose your dream design! We could also organize a meeting to decide this together.

Currently, if a user wants to create a blog post with images, they must use link to external images on the web.
There is no way to upload images to the server and link them in the blog post.

Few steps to tackle this:

• Handle image upload in the backend. A solution could be to add a gallery section to each user, and to allow users to upload images.
• Find a easy way to integrate image upload when uploading a md article.

I want to propose the next milestone for the website, and I wanted to discuss about it before creating it.

Create a private space for authenticated users on the blog website to manage published articles.
New features:

• Personal space for each authenticated users
• Management of posts (add, remove, edit)
• Management of personal data (avatar, name, email, password)

Let me know what you think!

I installed prettier, and it works, but the rule doesn’t. When I do npm run pretty in the main folder of the repo, I get this:

[email protected] pretty
npx prettier --write ‘**/*.{js,md,yml,css,html}’ ‘!mongodb/**’
[error] No files matching the pattern were found: “‘**/*.{js,md,yml,css,html}’”.
[error] No files matching the pattern were found: “‘!mongodb/**’”.

I’m on Windows. I googled this error, and it may have sth to do with the quotes.

I copied the readme file to another folder and was able to format it with prettier --write. I tried it on a copy for now, because I thought you’d prefer people to run the script. Let me know if it makes any difference. If not, I’ll format the file and push it. Or let me know if I need to do anything to make the rule work on my computer.

Originally posted by @OlaPom in #96 (comment)

As you know, we keep track of the repo structure in the README, and it's a very useful feature for new developers on this project!
However, it's very boring to update it by hand at each PR.
I don't see any solution but I'm sure we can do something about this. At least but an alert or a github action that remind us to do it at each PR!

See attached screenshot. Happens on article preview, main blog page, and when reading the details of an article.
Issue happens on Chrome version 105/106 and Firefox version 105 on Windows 10.

This is an aesthetic issue, and it is very unlikely to happen in a real world usecase, but it would be nice to fix it nonetheless.

Discussed in #52

Context:

Recently @atxr opened two amazing PR (#1 and #2) to deploy the first version of the iScsc blog.

Issue:

The reviewing step is taking faaaaaaar too long (almost 1 month for me to review #1 maybe 15 days to merge it, same for #2).

Causes:

I personally identified 3 root causes:

• these PR are quite long (65 commits for #1 38 for #2 if I'm right) --> I hope this is because there are needed to write the blog structure
• none of us are familiar with React neither are expert in JS or simply web coding --> we don't know were to start
• we miss documentation, context and concrete facts to imagine the code we're reviewing in action and identify flaws

Solutions:

these solutions/advice are not addressed to @atxr but to any maintainer on this repo or even others

• try as much as possible to write shorter PR, even if it means merging incomplete code like models and controllers which aren't useful at the time
• better introduce the PR, especially because there are the first/they introduce new concepts/framework!! Try to explain them to us and maybe link images
• actual commits are really good but try as much as possible (once again we're still noobs) to detailed your commit bodies that can be really helpful!
• send links/documentation that address the PR to help us understanding it
• and the MOST important. Reviewers: try to DO your JOB please. I'm the first to lack time and to take long to review code but reviewing is as boring and difficult as it is vital and encouraging for the developer.
  For the sake of developers motivation and this project future please review.

My real point:

First of all, the long reviewing time is an insidious flaw because it not only lower the maintainer motivation but also drive away the reviewers from their duty AND the project. Taking time to review delays a PR merging but also next features development! Please think about it, not reviewing code is killing the project!

Moreover when you're on the developer side it's so amazing and motivating to have feedback and review, we're all on both side so do it and others will!

However another problem arisen to me when reviewing @atxr PRs. #2 introduces user auth, and we can't even take the time to review this widely critical features, because we deeply miss the expertise to do it right. Let me write it straight. We are not able to develop and review really safe code because we aren't cyber-security experts.

Then what do we do? I'll open another Issue to discuss this deeply different problem.

I think that this Issue concerns everyone so here I go: @atxr @amtoine @J3y0 @Turtyo