shareplum icon indicating copy to clipboard operation
shareplum copied to clipboard

Folder operations on sites with read only permisisons

Open Gordonei opened this issue 3 years ago • 0 comments

Firstly, thanks for this awesome project!

Overview of Issue

Upon initialisation of the folder object, _create_folder is called, which does a POST request against /_api/web/folders.

If the folder doesn't exist, it creates it, and returns the relevant information on the folder, including the ServerRelativeUrl. If the folder already exists, it just returns the relevant information on the folder. In my opinion, it's a bit odd that the SP API makes this a POST, but that is besides the point. If you want, you can do a GET, as per #161

However, I find if my user only has read authorisation on the SP folder, I get 401 from the /_api/web/folders endpoint, regardless if I do a GET or PUT. Since I'm not interested in mutating the folder, I can do without most of self.info, but in a few places, ServerRelativeUrl is used (e.g. get_file).

Workaround

Using the power of monkey patching, it is possible to work around this (at least on the SharePoint install I'm working with)

import shareplum.folder


def _post_but_no_errors(session, url, **kwargs):
    return session.post(url, **kwargs)


def _get_file_no_create(self, file_name):
    site_base_path = '/'.join(self.site_url.split('/')[3:])
    response = shareplum.folder.get(
        self._session,
        self.site_url + (
            f"/_api/web/GetFileByServerRelativeUrl('"
            f"/{site_base_path}/{self.folder_name}/{file_name}')/$value"
        )
    )
    return response.content


if __name__ == "__main__":
    # apply monkey patches
    shareplum.folder.post = _post_but_no_errors
    shareplum.folder._Folder.get_file = _get_file_no_create

    # rest of code here

Longer term solution

As per my workaround above, in my installation, it is possible to infer the relative URL without the return from the _create_folder call - it's just the SP base path, along with the folder name.

My first question is whether this holds for other SP installations, and secondly, if this is the case, would there be any other issues with changing the behaviour of this class to rather not rely upon _create_folder succeeding?

I can appreciate that there might be people relying upon the current behaviour of folders being created when initialising the object.

Gordonei avatar Jun 14 '22 21:06 Gordonei