-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Clarify the description of REST vs OCS in accordance to sugestions discussed #12264
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Christian Wolf <github@christianwolf.email>
Signed-off-by: Christian Wolf <github@christianwolf.email>
@provokateurin I started to rephrase the "do not use OCS" in this PR. Does this sound reasonable or am I going completely the wrong direction? I know I need to eventually write a few more words and I for sure have to check the table entries (and wanted to explain them a bit more). What do you think, makes this sense? Is this to be discussed with some guys from the core team before merging (as it reverts some basic strategic statement)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot, this is already super helpful!
The RST syntax for the table really messed with my brain, I need to take a closer look at it in proper table shape.
@@ -183,7 +183,7 @@ | |||
#'pointsize': '10pt', | |||
|
|||
# Additional stuff for the LaTeX preamble. | |||
'preamble': '\extrafloats{100}\maxdeadcycles=500\DeclareUnicodeCharacter{274C}{\sffamily X}', | |||
'preamble': '\\extrafloats{100}\\maxdeadcycles=500\\DeclareUnicodeCharacter{274C}{\\sffamily X}', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just got a warning from sphinx/LaTeX when trying to build the PDF dev documentation locally. I wanted to get rid of any warnings, so this was part of the process.... I suspect this can be seen as resolved.
Offering a RESTful API is not different from creating a :doc:`route <../basics/routing>` and :doc:`controllers <../basics/controllers>` for the web interface. It is recommended though to inherit from ApiController and add **@CORS** annotations to the methods so that `web applications will also be able to access the API <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>`_. | ||
Offering a RESTful API is not different from creating a :doc:`route <../basics/routing>` and :doc:`controllers <../basics/controllers>` for the web interface. | ||
It is recommended though to inherit from ApiController and add **@CORS** annotations to the methods so that `web applications will also be able to access the API <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>`_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No relevant diff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just styling to put every sentence on it's own line. I can drop that as well.
Keep in mind that multiple apps will likely depend on the API interface once it is published and they will move at different speeds to react to changes implemented in the API. Therefore it is recommended to version the API in the URL to not break existing apps when backwards incompatible changes are introduced:: | ||
Keep in mind that multiple apps will likely depend on the API interface once it is published and they will move at different speeds to react to changes implemented in the API. | ||
Therefore it is recommended to version the API in the URL to not break existing apps when backwards incompatible changes are introduced:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
The following combinations of attributes might be useful for various scenarios: | ||
|
||
#. Plain frontend route: No special attribute related to CSRF or CORS | ||
#. Plain Frontend with CRSF checks disabled: Add the ``#[NoCSRFRequired]`` attribute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CSRF checks should only be disabled when absolutely necessary, this line should have a big warning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are some of the few words I wanted to add...
The following combinations of attributes might be useful for various scenarios: | ||
|
||
#. Plain frontend route: No special attribute related to CSRF or CORS | ||
#. Plain Frontend with CRSF checks disabled: Add the ``#[NoCSRFRequired]`` attribute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#. Plain Frontend with CRSF checks disabled: Add the ``#[NoCSRFRequired]`` attribute | |
#. Plain Frontend with CRSF checks disabled: ``Controller`` class and ``#[NoCSRFRequired]`` attribute on the method |
#. Plain frontend route: No special attribute related to CSRF or CORS | ||
#. Plain Frontend with CRSF checks disabled: Add the ``#[NoCSRFRequired]`` attribute | ||
#. REST route with CORS enabled: Add the ``#[CORS]`` attribute | ||
#. OCS-based route |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is another case with OCS+CSRF
Co-authored-by: Kate <26026535+provokateurin@users.noreply.github.com> Signed-off-by: Christian Wolf <github@christianwolf.email>
Signed-off-by: Christian Wolf <github@christianwolf.email>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good now!
#. Plain frontend route: ``Controller`` class | ||
#. Plain Frontend with CRSF checks disabled: ``Controller`` class and ``#[NoCSRFRequired]`` attribute on the method | ||
#. OCS-based route: ``OCSController`` class | ||
#. OCS-based route with CSRF disabled: ``OCSController`` class and ``#[NoCSRFRequired]`` attribute on the method |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this case doesn't exist, NoCSRFRequired should not have an effect on OCSController, but I will have to check that in the code to be sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking back and forth on this as well. In the end, I decided to keep the case as there is a certain difference (at least from the implementation):
For methods with NoCSRFRequired
, this section is doing nothing.
For the case where the attribute is not given, the strict cookie check boils down to a check on the OCS-APIREQUEST
header or no valid session token.
With the header in place (as the OCS controller generally expects), the second part is also skipped: The CSRF check is hardcoded to true, thus isInvalidCSRFRequired
returns false.
When the header is not set, you enter the second if block and will check the inner if. The check isinstance OCSController
is obviously true. The isValidOCSRequest
is somewhat redundant as it can only be reached with the header unset. Alternatively, a bearer authorization header is sufficient to make the CSRF checker happy (even without OCS header and without NoCSRFRequired
attribute).
I was adding this case as a reaction on your statement
There is another case with OCS+CSRF
In my opinion the last case could be dropped (and was never planned in the first round) but I do not see clearly the motivation of it, to be honest. Did I misunderstand your statement above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion the last case could be dropped (and was never planned in the first round) but I do not see clearly the motivation of it, to be honest. Did I misunderstand your statement above?
I messed up, I meant OCS+CORS...
Currently the CORS cases are completely missing in the list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, okay, then that makes more sense. I can read the cors posts and extend by the OCS+cors as well.
I will add a warning about cors in general similar to csrf of you do not mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you have any idea how to describe the case Access from external website more precisely or otherwise better, feel free to comment 😉.
Signed-off-by: Christian Wolf <github@christianwolf.email>
08e4aab
to
ca6794c
Compare
Signed-off-by: Christian Wolf <github@christianwolf.email>
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
@provokateurin are you still looking some things up, is there any action from my side required at the moment, or was there simply no time to review/prepare merging? |
No sorry, I was just busy with other things. I'll take another look in the coming days 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some links to general resources like these would be nice:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://developer.mozilla.org/en-US/docs/Glossary/CSRF
- *Access from an external app* indicates that the user is not using the normal browser (as logged in) but directly navigates a certain URL. | ||
This can be in a new browser tab or an external program (like an Android app or simply a curl command line). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what these two cases have in common.
Security wise they are also a bit different, since you need CSRF protection to prevent redirect attacks via GET while this is completely irrelevant for non-browser use cases like curl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They have in common that the CSRF token is not (guaranteed to be) known as part of the Cookie header and that the user is doing a dedicated action to navigate there (not by using a JS/AJAX request).
You are right these might be considered as separate cases. From user perspective (what can be done? not what is secure?), both navigate to an arbitrary URL and fetch the data. Examples:
- The user navigates to http://cloud.example.com/apps/cookbook/recipe/1234 the basic HTML template should be rendered in the browser and load the recipe 1234. If the actual call to the HTML template would be CSRF-protected any bookmarked link would break.
- An app wants to fetch data from the cookbook using a REST-based API http://cloud.example.com/apps/cookbook/api/v1/recipes/1234. Here, the CSRF checks might cause trouble as well prohibiting legitimate access to the endpoint.
I have not worked out the security side of this. What do you mean by redirect attacks via GET?
Fix typos and other errors in the code as suggested by review process Co-authored-by: Kate <26026535+provokateurin@users.noreply.github.com> Signed-off-by: Christian Wolf <github@christianwolf.email>
☑️ Resolves
🖼️ Screenshots
T.B.D.