n3oltd / N3O.Umbraco

N3O extensions to the Umbraco CMS
MIT License
3 stars 3 forks source link

Authenticated API for creating and managing fundraising pages #381

Closed nadrummond closed 1 week ago

nadrummond commented 9 months ago

As the editing of pages will take place via JavaScript we need to implement an API for storing these changes in the Umbraco content tree.

The APIs will need to be authenticated which means using MemberAuthorize but also, each page is owned by one or more members so we need to add our own additional authorization filter to make sure the member making the request is listed on the page as owning it.

As per the design shown below editing a page involves opening a modal of a certain "type" such as textbox, rich text, image cropper etc. It seems to make sense therefore that our endpoints are 1 per type to match this. So, for example we might have

/api/crowdFunding/pages/{pageId}/properties/{propertyId}/text

{
    value:  string
}

and also

/api/crowdFunding/pages/{pageId}/properties/{propertyId}/richText

{
    value:  string
}

and

/api/crowdFunding/pages/{pageId}/properties/{propertyId}/image

{
    value:  image bytes, url or whatever
}

Essentially the frontend developers will code up 1 modal per type of edit component and when it is invoked the two parameters that are supplied are the pageId (Umbraco content key) and also the name of the property to persist the value into.

We should be resilient against people posting garbage values for the property ID or payload, especially as this is a public site.

image

nadrummond commented 9 months ago

Note on the above, as we will also be allowing people to edit team pages it maybe makes sense that we don't put these routes under pages, but instead a more generic content API under crowd funding so they can be shared between the teams and pages frontend editors.

The specific endpoints under the pages (or teams route) should be operations against the entity, e.g. /close, /open, /addPage, /editAllocation etc.