Skip to end of metadata
Go to start of metadata

Require user authentication in Core - and implement ACL in there

Pro

Con

 Very secure interface

 Lot's of work in the Core UI to be done

 REST-API could be extended to remote clients
(not Localhost only)

 you would need to authenticate to the Core

 

 difficult to know for WebUI what it is allowed to show

Pass Optional User Levels with each item you get via REST (by wacky, benste)

Pro

Con

 each UI could access these Level directly while working with an item

Messing up the item

ACLs are treated optional - e.g. plugins could enable additional feautres

Lack of security once you've got Web Plugins

very easy to show and hide items in the WebUI based on ACL

this only applys for list style values, not for actions

 

 complete rewrite of REST needed

 

 user-levels could be treated in DOC

 

Do we already have other than the mailman-web Django Project who access REST ?

Use another Middleware (by barry)

Reasons for running REST-API as root@localhost:

  • keeps the REST API simple
  • keeps the Data Model simple
  • clients have unlimmited functional flexibility
  • not locked into the core's perception of permissions and security
    VS: requiring every client to implement security, access and permissions

It could do the permission check, filter the request as
appropriate, and forward it to the core. Of course, responses could also be
filtered if necessary, but this would present exactly the API that clients
required.

It's also supposed to do Authentification

Pro

Con

not messing up REST neither CORE

cloning REST-Api with additional informations (if there is no possibility to check method calls e.g as a list)

pluggability and customization for
various environments

need to write a site plugin to use another authentification framework

 

 

Implement it in the WebUI only

Pro

Con

No need to change Core

 every UI would need to it again - e.g taking a look at the documentation
Very big workload for every UI