classes could be created without a "creator"

[JumanaFM]

to reproduce error:

• clear cookies but remain on the main dashboard.
• create a class after your cookies were cleared.
• the class will be added to the DB with "null" as the "creator" value.
• class will not be loaded to the UI.

this is a problem also for people who leave their tabs open but have their session cleared, we shouldn't allow requests without any authentication which is also a problem with other parts in the system that needs to be handled.

[karger]

This points to a broader problem.   Any actions that modify data should be access controlled and done only when identity is verified and access granted.   I assumed that the nodejs infrastructure would handle this for us; what have we done that enabled unauthenticated access to change state?

…

On 1/4/2021 3:40 PM, Jumana Almahmoud wrote: to reproduce error: * clear cookies but remain on the main dashboard. * create a class after your cookies were cleared. * the class will be added to the DB with "null" as the "creator" value. * class will not be loaded to the UI. this is a problem also for people who leave their tabs open but have their session cleared, we shouldn't allow requests without any authentication which is also a problem with other parts in the system that needs to be handled. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#64>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIWSXXYEVWXG67BRUAQRSDSYIRUBANCNFSM4VTQ3T4A>.

[JumanaFM]

I agree. I noticed this bug when Marc pointed out he wasn't able to see one of his classes in his list. The original implementation of nb doesn't always check the current user (authenticated or not).

[karger]

On 1/4/2021 5:28 PM, Jumana Almahmoud wrote: I agree. I noticed this bug when Marc pointed out he wasn't able to see one of his classes in his list. The original implementation of nb doesn't always check the current user (authenticated or not).

I would assume this checking would happen on all api calls by default---how does it fail to happen?

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIWSXQS2PTJ4EDTLKRFVV3SYI6JLANCNFSM4VTQ3T4A>.

[JumanaFM]

On 1/4/2021 5:28 PM, Jumana Almahmoud wrote: I agree. I noticed this bug when Marc pointed out he wasn't able to see one of his classes in his list. The original implementation of nb doesn't always check the current user (authenticated or not).
I would assume this checking would happen on all api calls by default---how does it fail to happen?
…
— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIWSXQS2PTJ4EDTLKRFVV3SYI6JLANCNFSM4VTQ3T4A.

from what I have seen in the code, once the UI is loaded, it will send an api/user/current request to check if the user has a valid session, if not it will redirect to the log in page. So, as long as the page is loaded and a user was authenticated, all other requests (i believe so) assumes that a user have a valid session, which i think is not a good approach. We need to check before every action. No just for this issue but to mitigate any other anonymous requests (from postman for example and so on). I'm thinking of solving this by creating a middleware that intercepts all requests to check if they were valid.