Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2011-05-27 07:57:56
Size: 1893
Editor: benste
Comment:
Revision 5 as of 2011-05-27 14:27:29
Size: 3206
Editor: benste
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#pragma page-filename DEV/versions/11960545 #pragma page-filename DEV/versions/11960552
Line 10: Line 10:
<<Color2(&nbsp;REST-API could be extended to remote clients, col=#339966)>><<BR>> <<Color2(&nbsp;REST-API could be extended to remote clients, col=#339966)>><<BR>> <<Color2((not Localhost only), col=#339966)>><<BR>>
Line 16: Line 16:
== Pass Optional User Levels with each item you get via REST == == Pass Optional User Levels with each item you get via REST (by wacky, benste) ==
Line 35: Line 35:
==

|| <<Color2(Do we already have other than the mailman-web Django Project who access REST ?, col=#0000ff)>><<BR>>
}}}
== 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.

{{{#!table
'''Pro <<BR>>'''
|| '''Con'''
==
<<Color2(not messing up REST neither CORE, col=#339966)>> <<BR>>
|| <<Color2(cloning REST-Api with additional informations, col=#ff0000)>><<Color2((, col=#ff0000)>><<Color2(if there is no possibility to check method calls e.g as a list), col=#0000ff)>><<BR>>
==
<<Color2(pluggability and customization for, col=#339966)>><<BR>><<Color2(various environments, col=#339966)>> <<BR>>
|| <<Color2(&nbsp;, col=#ff0000)>>
==
<<Color2(&nbsp;, col=#339966)>>
|| <<Color2(&nbsp;, col=#ff0000)>>
Line 42: Line 72:
|| <<Color2(&nbsp;every UI would need to it again - e.g taking a look at the documentation, col=#ff0000)>><<BR>><<Color2(Very big workload for every UI, col=#ff0000)>><<BR>> || <<Color2(&nbsp;every UI would need to it again - e.g taking a look at the documentation, col=#ff0000)>><<BR>> <<Color2(Very big workload for every UI, col=#ff0000)>><<BR>>

Require user authentication in Core - and implement ACL in there

Pro Con
&nbsp;Very secure interface
&nbsp;Lot's of work in the Core UI to be done
&nbsp;REST-API could be extended to remote clients
(not Localhost only)
&nbsp;you would need to authenticate to the Core
&nbsp; &nbsp;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
&nbsp;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
&nbsp;complete rewrite of REST needed
&nbsp; &nbsp;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.

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
&nbsp;
&nbsp; &nbsp;

Implement it in the WebUI only

Pro Con
No need to change Core
&nbsp;every UI would need to it again - e.g taking a look at the documentation
Very big workload for every UI
&nbsp; &nbsp;
&nbsp;

MailmanWiki: DEV/Pro - Con ACL in different Layers (WebUI) (last edited 2011-05-27 14:30:05 by benste)