|
Size: 1893
Comment:
|
Size: 2064
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/11960549 |
| Line 10: | Line 10: |
| <<Color2( REST-API could be extended to remote clients, col=#339966)>><<BR>> | <<Color2( REST-API could be extended to remote clients, col=#339966)>><<BR>><<Color2((not Localhost only), col=#339966)>><<BR>> |
| Line 35: | Line 35: |
| == || <<Color2(Do we already have other than the mailman-web Django Project who access REST ?, col=#0000ff)>><<BR>> |
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
| 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 |
| 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 ? |
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 |
| | |
| |