editoast: no nesting checks between projects, studies and scenarios

[Math-R]

What happened?

With the new router implementation in the front part of the application, the user know can access projects, studies, and scenarios using some parameters in the url.

Projects :
operationnal-studies/projects/{projectId}

Studies :
operationnal-studies/projects/{projectId}/studies/{studyId}

Scenario :
operationnal-studies/projects/{projectId}/studies/{studyId}/scenarios/{scenarioId}

All ids are unique in the DB.

But if the user try to access scenario : 4, he can do it from all the studies :

operationnal-studies/projects/1/studies/1/scenarios/4 => work
operationnal-studies/projects/2180/studies/1/scenarios/4 => work
operationnal-studies/projects/1/studies/850/scenarios/4 => work

Actually the API asks the ids for project, study , and scenario, but just to check if there are some existing ones but not if they're linked together.

What did you expect to happen?

Back must throw a 404 error when the id nesting is not consistent

How can we reproduce it (as minimally and precisely as possible)?

Create a 2 projects and 2 studies

Try to access the study hold by project 1 using the id of project 2

You will retrieve the study even if the project id is not the right one

What operating system, browser and environment are you using?

• Browser: Firefox v109
• OS: Nixos v22.11
• Env: Local

OSRD version (top right corner Account button > Informations)

5c88cf6

[leovalais]

Good catch, my take on this would be to get rid of the nesting which brings no benefit since you already have a scenario ID. The nesting would be useful if scenarios that belong to different projects could share the same identification key (such as their name by example) that we could use to identify them. But that's not our case.

@Math-R does the url nesting or the inclusion check bring any benefit to the front?

@osrd-project/editoast-maintainers Wdyt? We could still check the inclusion using for instance optional URL parameters, like editoast:/scenario/1?project=1&study=42

[Tristramg]

From a rest point of view, I’d say /scenario/{id} seems to be enough and we don’t need that nesting (and maybe the same for /studies ?)
I’m not sure about the need for a coherence check and I find it a bit weird, but maybe there are some reasons I don’t know to double check that the scenario really belongs to a given study. As the issue is flagged major, I’m probably missing a point here

[flomonster]

We wanted to keep a nesting endpoint cause we'd like to replace IDs with slugs in the near future. I don't yet know how this will be done but the unicity property may no longer be valid.