|
Size: 3314
Comment:
|
← Revision 7 as of 2011-05-27 14:30:05 ⇥
Size: 2525
Comment: Migrated to Confluence 4.0
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma page-filename DEV/versions/14352750 | #pragma page-filename DEV/versions/11960537 |
| Line 3: | Line 3: |
| Line 4: | Line 5: |
| '''Pro''' || '''Con <<BR>>''' |
'''Pro ''' || '''Con <<BR>> ''' |
| Line 7: | Line 10: |
| <<Color2( Very secure interface, col=#339966)>><<BR>> || <<Color2( Lot's of work in the Core UI to be done, col=#ff0000)>><<BR>> |
Very secure interface<<BR>> || Lot's of work in the Core UI to be done<<BR>> |
| Line 10: | Line 14: |
| <<Color2( REST-API could be extended to remote clients, col=#339966)>><<BR>> <<Color2((not Localhost only), col=#339966)>><<BR>> || <<Color2( you would need to authenticate to the Core, col=#ff0000)>><<BR>> == <<Color2( , col=#339966)>> || <<Color2( difficult to know for WebUI what it is allowed to show, col=#ff0000)>><<BR>> }}} == Pass Optional User Levels with each item you get via REST (by wacky, benste) == {{{#!table '''Pro''' || '''Con <<BR>>''' == <<Color2( each UI could access these Level directly while working with an item, col=#339966)>><<BR>> || <<Color2(Messing up the item, col=#ff0000)>> <<BR>> == <<Color2(ACLs are treated optional - e.g. plugins could enable additional feautres, col=#339966)>> || <<Color2(Lack of security once you've got Web Plugins, col=#ff0000)>><<BR>> == <<Color2(very easy to show and hide items in the WebUI based on ACL, col=#339966)>><<BR>> || <<Color2(this only applys for list style values, not for actions, col=#ff0000)>><<BR>> |
REST-API could be extended to remote clients<<BR>> (not Localhost only)<<BR>> || you would need to authenticate to the Core<<BR>> |
| Line 31: | Line 20: |
| || <<Color2( complete rewrite of REST needed, col=#ff0000)>><<BR>> | || difficult to know for WebUI what it is allowed to show<<BR>> }}} == Pass Optional User Levels with each item you get via REST (by wacky, benste) == {{{#!table '''Pro ''' || '''Con <<BR>> ''' |
| Line 33: | Line 31: |
| <<Color2( , col=#339966)>> || <<Color2( user-levels could be treated in DOC, col=#ff0000)>><<BR>> |
each UI could access these Level directly while working with an item<<BR>> || Messing up the item <<BR>> == ACLs are treated optional - e.g. plugins could enable additional feautres || Lack of security once you've got Web Plugins<<BR>> == very easy to show and hide items in the WebUI based on ACL<<BR>> || this only applys for list style values, not for actions<<BR>> |
| Line 37: | Line 45: |
| || <<Color2(Do we already have other than the mailman-web Django Project who access REST ?, col=#0000ff)>><<BR>> | || complete rewrite of REST needed<<BR>> == || user-levels could be treated in DOC<<BR>> == || Do we already have other than the mailman-web Django Project who access REST ?<<BR>> |
| Line 39: | Line 55: |
| Line 40: | Line 57: |
| Line 45: | Line 63: |
| * not locked into the core's perception of permissions and security VS: requiring every client to implement security, access and permissions |
* not locked into the core's perception of permissions and security<<BR>> VS: requiring every client to implement security, access and permissions |
| Line 48: | Line 65: |
| 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 could do the permission check, filter the request as<<BR>> appropriate, and forward it to the core. Of course, responses could also be<<BR>> filtered if necessary, but this would present exactly the API that clients<<BR>> required. |
| Line 56: | Line 70: |
| '''Pro <<BR>>''' || '''Con''' |
'''Pro <<BR>> ''' || '''Con ''' |
| Line 59: | Line 74: |
| <<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>> |
not messing up REST neither CORE <<BR>> || cloning REST-Api with additional informations (if there is no possibility to check method calls e.g as a list)<<BR>> |
| Line 62: | Line 78: |
| <<Color2(pluggability and customization for, col=#339966)>><<BR>><<Color2(various environments, col=#339966)>> <<BR>> || <<Color2(need to write a site plugin to use another authentification framework, col=#ff0000)>> |
pluggability and customization for<<BR>> various environments <<BR>> || need to write a site plugin to use another authentification framework |
| Line 65: | Line 83: |
| <<Color2( , col=#339966)>> || <<Color2( , col=#ff0000)>> }}} == Implement it in the WebUI only == {{{#!table '''Pro''' || '''Con <<BR>>''' == <<Color2(No need to change Core, col=#339966)>><<BR>> || <<Color2( 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( , col=#339966)>> || <<Color2( , col=#ff0000)>> == <<Color2( , col=#339966)>> |
|
| Line 82: | Line 86: |
== Implement it in the WebUI only == {{{#!table '''Pro ''' || '''Con <<BR>> ''' == No need to change Core<<BR>> || every UI would need to it again - e.g taking a look at the documentation<<BR>> Very big workload for every UI<<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 (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 |