[plone.restapi] Default configuration questions

Development Developing for Plone
1

Maybe someone with more insight to the restapi can answer those questions:

  1. Why are all services registered globally?
    The plone:service ZCML definition supports a layer attribute, but it is never used. So all services are enabled and available by default. Installing the add-on “only” adds the browserlayer and some default permissions (which are required for a successful api request). But once installed — no matter if it is uninstalled later — the restapi is available on that Plone site.

  2. Why can Anonymous use the restapi by default?
    Is it because some Plone components now use the restapi for interactive behaviors?

  3. Why is there no default limit for api requests?
    When performing a search request, it is possible to query all content items without a limit and getting the full objects. On a site with several thousand content types this will kill our servers — no matter how fast the restapi is compared to SSR.

Thanks,
Thomas

2

I agree, the layer applied would be useful, otherwise we do not need it.

I use plone.restapi as an endpoint for an external data synchronization application between Plone and another service. Here I do not want to have other users or anonymous to access restapi.

In my profiles rolemap.xml I define a new role and give it the permission have for sites. My user used for datasync gets this role assigned, but no one else.

<?xml version="1.0"?>
<rolemap>
  <roles>
    <role name="DataSync" />
  </roles>
  <permissions>
    <permission name="plone.restapi: Use REST API" acquire="False">
      <role name="Manager" />
      <role name="DataSync" />
    </permission>
  </permissions>
</rolemap>
3

@tmassman overall I think you should open 3 issues at Issues · plone/plone.restapi · GitHub - if not already covered by an open issue. This usually works better than at this forum.

4

My 2c:

  1. Good point. I guess we could do this.
  2. Exactly. Plone 6 (Volto) for instance. Since this is the main use case it should be the default IMHO.
  3. Good point/question as well. Because we believe this is something that should be taken care of by frontend servers.

In any case. PRs are always welcome. :slight_smile:

5

Thanks for your answers so far. I think with adding the layer attribute we can make this more solid, since no requests are possible anymore once uninstalled and so kind of “solves” unwanted and massive api requests from anonymous users.

Using the layer attribute we could also add the default CORS config from the docs. If required it can be customized by polilcy add-ons.

One thing I forgot yesterday is the possibility to have service api keys. IIRC I think @MrTango told me about some discussions with @tisto some time ago. Is this something that would make sense as an option to be enabled?

Anyway, I will add the tickets and prepare PRs. But now heading into the weekend :wink:

1 Like
6

Service API keys would definitely be a feature that we would want to have. If I recall correctly I think I also discussed this with @buchi, maybe he can chime in here as well.

1 Like
7

@tisto @tmassman for service api keys we have an addon: GitHub - 4teamwork/ftw.tokenauth: PAS plugin for machine-to-machine auth implementing two-legged OAuth2 using service keys and access tokens

1 Like
8

@buchi: Awesome! We should mention this on the REST API readme and docs.

9

Yes we talked about this in Ferrara during the sprint.
The ftw addon basically does what is needed, but is only working on Plone 4 and has a bit to many dependencies. So for the broader usage we need something for current Plone and best with less dependencies.

10

I don't see that much of a problem with the dependencies tbh. We could upgrade the package to work with Plone 5/6. Though, if someone is willing to create a PR to add this functionality into plone.restapi core I wouldn't mind either. Would be a good sprint topic...

11

I would not add this functionality into plone.restapi as it's not limited to REST API requests. It's implemented as a PAS plugin that works with any kind of requests.

Adding support for Python 3 and the latest Plone versions should be easy but I will have to check that.

12

Right. Then it makes sense to keep that as a separate add-on. In the long run, the question might be if we want to ship this with core. Then we would have to discuss the dependencies. Until then this shouldn't be an issue IMHO.

13

I agree, a pas.plugins.tokenauth for 5/6 (or an updated ftw.* ) would be awesome.

14

We may have a usecase for this in the coming weeks for a new site and definitely will look at and upgrade if needed.

15

Maybe forcing a max batch-size for those queries would help the best here.

16

That does not make much sense IMHO because it only limits the response size and does not solve the real problem (which we have to solve anyways). It also limits an important and valid use case which is to get unbatched results (e.g. if you actually want
to retrieve all the data, not all use cases include a JS-based and publicly exposed front-end).

17

Most APIs I know do not provide unbatched results, but provide a batch of N and a link to fetch the next N results. Just as an idea.

18

Results are batched by default: Batching — plone.restapi 1.0a1 documentation

This discussion totally went off-topic...

1 Like
19

Maybe we can set an option with some sensible defaults which is adjustable by admins (control panel). A public facing Plone site should be more restricted than an internal site IMHO.

20

That might be an option. Though, I believe that we have to approach the issue a bit broader. Public APIs usually require a more sophisticated rate limit system and IMHO we should look for existing solutions outside of plone.restapi that properly handle this use case instead of re-inventing the wheel. Though, tbh this is just my gut feeling. I haven't done any research in that direction...

If anyone wants to look into this and do some research I'd be happy to hear what we can do about it.