Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] REST API v2.1.0: GET /api/v2/cases/{identifier}/iocs #537

Open
Elise17 opened this issue Jul 17, 2024 · 5 comments · Fixed by #597
Open

[FR] REST API v2.1.0: GET /api/v2/cases/{identifier}/iocs #537

Elise17 opened this issue Jul 17, 2024 · 5 comments · Fixed by #597
Assignees
Labels
enhancement New feature or request

Comments

@Elise17
Copy link
Contributor

Elise17 commented Jul 17, 2024

This issue is about the implementation of the first iocs endpoint:

  • GET /api/v2/cases/{identifier}/iocs

The tasks are the following:

  • document the new API in the openapi documentation
  • implement automatic tests+code
  • deprecate the previous endpoint both in the code and in the documentation
  • replace the previous endpoint with the new one in the web interface
  • factorize the function code get_detailed_iocs for the new URL
  • add get_ioc_link in iocs for POST and DELETE /api/v2/iocs

Create a test :

  • create two cases
  • create two iocs in each cases
  • check in each cases that we get one ioc

This is the previous endpoint which should be deprecated:

  • GET /case/ioc/list

In the web interface:

  • GET /case/ioc/list in case.ioc.js
@Elise17 Elise17 added the enhancement New feature or request label Jul 17, 2024
@Elise17 Elise17 assigned Elise17 and c8y3 and unassigned Elise17 Aug 9, 2024
@c8y3
Copy link
Contributor

c8y3 commented Aug 12, 2024

Things that need to be completed:

  • avoid returning the state
  • one line per import
  • inline build_filter_ioc_query (or make it private)
  • create 2 cases with each one ioc, check the list returns only one ioc in each case
  • factor get_filtered_iocs and get_detailed_iocs (previous endpoint implementation) => Won't do, too difficult and of little value since get_detailed_iocs will be dropped once the previous deprecated endpoint is removed.
  • change url to GET /api/v2/cases/{identifier}/iocs
  • check all uses of annotation ac_requires_case_access, check the accesses are verified against the right case identifier. Add test and fix if not.
  • GET /api/v2/iocs/int:cur_id, DELETE /api/v2/iocs/int:cur_id should do the access control check to the case in code, rather than in annotation (there is no access to the case identifier from the request only)
  • case_ioc_dbs.get_ioc: remove case_id parameter, no need for it
  • case_ioc_dbs.delete_ioc: remove case_id parameter, no need for it
  • business.iocs.iocs_update: remove case_identifier parameter, no need for it

@c8y3 c8y3 changed the title [FR] REST API v2.1.0: GET /api/v2/iocs [FR] REST API v2.1.0: GET /api/v2/cases/{identifier}/iocs Aug 12, 2024
@c8y3
Copy link
Contributor

c8y3 commented Sep 4, 2024

  • Should check all permission rights declared on the /api/v2/ cases routes.
  • Should check all permission rights declared on the /api/v2/ tasks routes.
  • Should check all permission rights declared on the /api/v2/ iocs routes.
  • Should check all permission rights declared on the /api/v2/ assets routes.

@c8y3
Copy link
Contributor

c8y3 commented Sep 4, 2024

Architecture hint and reflexion: for the IOC delete in the new API, since the case identifier is not present on the request, the case access permission check can only be done in the business level, after the ioc is retrieved.
This hints that, maybe, the permission checks (or at least the case accesses checks?) should all be done at this level...
Think about it...

Actually we should decide on which layer we want to do it, then it will have an impact on the business API.

@c8y3
Copy link
Contributor

c8y3 commented Sep 11, 2024

In the end, I removed all permission checks out of business and put them in the blueprint layer. This has an impact on the signature of some methods in the business layer. But the end-result seems quite acceptable. I added the information about this choice in the architecture.md file.

@c8y3
Copy link
Contributor

c8y3 commented Sep 13, 2024

Here are the things remaining to do to update the documentation:

  • add tag beta for all new api endpoints
  • extract all resources in external files
  • check all new endpoints are documented
  • document missing GET /api/v2/cases/{identifier}/iocs
  • document missing GET /api/v2/cases
  • check object return types are uniform across all cases endpoints
  • check object return types are uniform across all iocs endpoints. Fields link and tlp are missing in POST and GET
  • check object return types are uniform across all assets endpoints
  • check object return types are uniform across all tasks endpoints

@c8y3 c8y3 mentioned this issue Sep 25, 2024
@c8y3 c8y3 linked a pull request Sep 25, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants